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@ System for integrating application programs in a heterogeneous network envlroment 

(g) A system which integrates applications that run on a plurality of homogenous or heterogeneous computers 
on a network. System Configuration files (510) in source code are created from a high level definition of the 
distributed system (LAN) which is to be Integrated. The configuration files (510) include data such as the types 
and formats of data for each process (402) on each node (400) of the system, identification of all applications 
and machine types, topography and the data manipulations needed for sending messages and files and the like 
from an application program in a first computer language and of a first data type to an application program in a 
second computer language and of a second data type. Node-specific data manipulation modules (DMM 528) are 
formed at each node (400) during startup of the system, and these modules are automatically distributed to 
nodes (400) on the network having the same architecture. The invention allows applications having different 
physical data characteristics to communicate by using the data manipulation modules (DMM 528) so formed to 
manipulate the data at the source program into a common data representation (CDR) having data types common 
to all of the languages represented by the system and then reconverting the data to the local representation at 
the destination node. 
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BACKGROUND OF THE INVENTION 



Field of the Invention 

5 The present invention relates to a system for integrating existing application programs in a networked 

environment, and more particularly, to a system with mechanisms for transforming and manipulating data 
messages for transfer between different applications on the same computer or on different computers 
connected via a network or networks and having the same or different computer architectures. 

10 Description of the Prior Art 

Since the beginning of the computer age. computers and, in particular, computer software programs 
have been used in a variety of settings to automate processes which were previously conducted 
mechanically. This automation has typically led to improved efficiency and increased productivity. However, 

75 because of the costs of such automation, automation of large businesses and factories has often been 
conducted on a piecemeal basis. For example, different portions of an assembly line have been automated 
at different times and often with different computer equipment as a result of the varying functionalities of the 
various computer systems available at the time of purchase. As a result, many assembly lines and 
businesses have developed "isfanas of automation" in which different functions in the overall process are 

20 automated but do not necessarily communicate with one another. In addition, in the office environment 
LANs have been used to allow new computer equipment to communicate; however, software applications 
typically may not be integrated because of data incompatibilities. 

Such heterogeneous systems pose a significant problem to the further efficiencies of automation since 
these different "islands of automation" and machines with incompatible data types connected to the same 

25 network cannot communicate with one another very easily. As a result, it has been difficult and expensive to 
control an entire assembly line process for a large manufacturing facility from a central location except on a 
piecemeal basis unless the entire factory was automated at the same time with homogeneous equipment 
which can intercommunicate. Thus, for those businesses and factories which have already been automated 
on a piecemeal basis, they are faced with the choices of eliminating all equipment so that homogeneous 

30 equipment may be substituted therefor (with the associated prohibitive costs) or waiting for the existing 
system to become obsolete so that it can be replaced (again at significant expense). 

One solution to the above problem has been to hire software programmers to prepare custom code 
which allows the different "islands of automation" to communicate with each other. However, such an 
approach is also quite expensive and is rather inflexible and assumes that the overall system remains static. 

35 In other words, when further equipment and application software must be integrated into the overall system, 
the software programmers must be called back in to rewrite the code for ail applications involved and to 
prepare additional custom code for interface purposes. A more flexible and less expensive solution is 
r>eeded. 

The integration of existing heterogeneous applications is a problem which has yet to be adequately 

4c solved. There are numerous major problems in such integration of existing applications because of the 
differences in hardware and their associated operating systems and because of the differences in the 
applications themselves. For example, because computers are built on proprietary hardware architectures 
and operating systems, data from applications runn::ig on one system is often not usable on another 
system. Also, programmers must frequently change application code to create interfaces to different sets of 

45 network services because of the diversity of such network services. In addition, different applications use 
different data types according to their specific needs, and, as a result, programmers must alter a receiving 
application's code to convert the data from another application into types that the receiving application can 
use. Moreover, incompatible data structures often result because of the different groupings of data elements 
by the applications. For example, an element with a common logical definition in two applications may still 

50 be stored in two different physical ways (i.e., application A may store it in one two-dimensional array and 
application B may store it in two one-dimensional arrays). Moreover, applications written in different 
languages usually cannot communicate with one another since data values are often interpreted differently. 
For example, C and FORTRAN interpret logical or boolean values differently. 

Partial solutions to the above problems have been proposed to provide distributed networks for allowing 

55 various applications to share data. In doing so. these applications have relied on transparent data sharing 
mechanisms such as Sun Microsystems' Network File System (NFS). AT&T's Remote File Sharing (RFS), 
FTAM (as defined by the MAP/TOP specifications), or Apollo's Domain File System. However, these 
systems are limited in that they allow data sharing but do not allow true integration of the different 
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application programs to be accomplished. 

Another example of a system for providing interprocess communication between different computer 
processes connected over a distributed network is the Process Activation and Message Support (PAMS) 
system from Digital Equipment Corp. This system generally allows processes to communicate with each 
other regardless of where the processes reside on a common network. Such processes may be located on 
a single CPU or spread across workstations, clusters, or local or wide area networks (LANs or WANs). The 
PAMs system manages all connections over the network and provides integration features so that 
processes on respective workstations, clusters and the like may communicate. In particular, the PAMs 
message processing system is a network layer which is implemented above other networks to transparently 
integrate new networks and events into a common message bus. Such a system enables network 
configuration to be monitored and message flow on the message bus to be monitored from a single point. 
The result is a common programming interface for all host environments to which the computer system is 
connected. Thus, all host environments appear the same to the user. 

For example, an ULTRIX host environment running ULTRIX-PAMS is directly connected to a VMS host 
running VAX-PAMS on its networks, and ULTRIX-PAMS uses VAX transport processes to route all 
messages over the network. Specific rules are then provided for routing messages using ULTRIX-PAMS 
and VAX transport processes, where the ULTRIX-PAMS functions as a slave transport in that it can only 
communicate to other PAMS processes via the network to a full function PAMS router. As a result, the 
PAMS system is limited in that there Is no support for "direct" task-to-task communications between 
ULTRIX processes. In addition, since all traffic must be routed through a VAX-PAMS routing node, a single 
point of failure exists for the system. 

Other systems have been proposed for an information processing environment in which various 
machines behave as one single integrated information system. However, to date such systems are limited 
to connecting various subroutines of homogeneous applications running on different machines connected to 
a common network. For example, the Network Computing System (NCS) of Apollo is a Remote Procedure 
Call (RPC) software package which allows a process (user application) to make procedure calls to the 
services exported by a remote server process. However, such RPC systems are typically not fit for the 
development of a networked transaction management system, for NCS does not provide a message and file 
handling system, a data manipulation system, a local and remote process control system and the like which 
allows for the integration of existing applications. Rather. NCS allows for the building of new distributed 
applications, and does not provide for the integration of existing heterogeneous applications, RPCs instead 
isolate the user from networking details and machine architectures while allowing the application developer 
to define structured interfaces to services provided across the existing network. 

RPCs can be used at different levels, for the RPC model does not dictate how they should be used. 
Generally, a developer can select subroutines of a single application and run them on remote machines 
without changing the application or subroutine code. The simplest use of RPCs is to provide intrinsic access 
to distributed resources which are directly callable by an application, such as printers, plotters, tape drives 
for backup tasks, math processors for complex and time-consuming applications, and the like. A more 
efficient use of RPC at the application level would be to partition the application so that the software 
modules are co-located with the resources that they use. For example, an application which needs to 
extract data from a database could be partitioned so that the modules which access the database could 
reside on the database machine. 

A diagram of NCS is shown in FIG. 1. The system 100 therein shown generally consists of three 
components: an RPC run time environment 132. 134 which handles packaging, transmission and reception 
of data and error correction between the user and server processes: a Network Interface Definition Compiler 
(NIDC) 136 which compiles high-level Network Interface Definition Language (NIDL) into a C-language code 
that runs on both sides of the connection (the user and server computers); and a Location Broker 128 which 
lets applications determine at run time which remote computers on the network can provide the required 
services to the user computer. In particular, as shown in FIG. 1, a user application 102 interfaces with a 
procedure call translator stub 104 which masquerades as the desired subroutine on the remote computer. 
During operation, the RPC run time system 106 of the user's computer and the RPC run time system 108 
of the server system communicate with each other over a standard network to allow the remote procedure 
call. Stub 110 on the server side, which masquerades as the application for the remote subroutine 112, then 
connects the remote subroutine 112 across the network to the user's system. 

The NCS system functions by allowing a programmer to use a subroutine cail to define the number and 
type of data to be used and returned by the remote subroutine. More particularly, NCS allows the 
application developer to provide an interface definition 114 with a language called the Network Interface 
Definition Language (NIDL) which is then passed through NIDL compiler 116 to automatically generate C 
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source code for both the user and server stubs. In other words, the NIDL compiler 116 generates stub 
source code 118 and 120 which is then compiled with RPC run time source code 122 by C compilers 124 
and 126 and linked with the application 102 and user-side stub 104 to run on th^ user's machine while the 
subroutine 112 and its server-side stub 110 are compiled and linked on the server machine. After the 

5 application 102 has been written and distributed throughout the network, location broker 128 containing 
network information 130 may then be used to allow the user to ask whether the required services (RPC) are 
available on the server system. 

Thus, with NCS, the NIDL compiler automatically generates the stubs that create and interpret data 
passed between an application and remote subroutines. As a result, the remote subroutine call appears as 

10 nothing more than a local subroutine call that just happens to execute on a remote host, and no protocol 
manipulations need to be performed by the application developer. In other words, the NCS system is 
primarily a remote execution service and does not need to manipulate data for transfer by restructuring a 
message to allow for conversion from one data type to another, A more detailed description of the NCS 
system can be found in the article by H. Johnson entitled "Each Piece In Its Place." Unix Review . June 

75 1 987. pages 66-75. 

The RPC system of the NCS primarily provides a remote execution service which operates synchro- 
nously in a clienVserver relationship in which the client and server have agreed in advance on what the 
requests and replies will be. Applications must be developed specifically to run on NCS or substantially 
receded to run on NCS. Moreover, because a remote procedure cannot tell when it will be invoked again, it 

20 always initiates communications at the beginning of its execution and terminates communications at the 
end. The initiation and termination at every invocation makes it very costly in performance for a remote 
procedure to set up a connection with its caller. As a result, most RPC systems are connectionless. This Is 
why RPC systems such as NCS must build another protocol on top of the existing protocol to ensure 
reliability. This overhead causes additional processing to be performed which detracts from performance. 

25 Accordingly, although NCS provides a consistent method for remote execution in a heterogeneous 
network environment, it is designed primarily to broker distributable services such as printing and plotting 
across the network, where the user may not care which printer prints the information as long as it gets 
printed. Another type of service might be providing processing time for applications where a small amount 
of data in a message can trigger an intensive and time consuming calculation effort to achieve an answer 

30 that can itself be turned into a message. However, the NCS system cannot provide a truly integrated 
system for incompatible node type formats and data processing languages. 

None of the known prior art systems address the substantial problems of integrating existing heteroge- 
neous application in a heterogeneous and/or homogeneous network environment. Accordingly, there is a 
long-felt need in the art for an integration system which provides for flexible data transfer and transformation 

36 and manipulation of data among existing applications programmed in a networked environment of heteroge- 
neous and/or homogeneous computers in a manner that is transparent to the user. The present invention 
has t>een designed to meet these needs. 

SUMMARY OF THE INVENTION 

40 

The Inventors of the subject matter disclosed and claimed herein have satisfied the above-mentioned 
long-felt needs in the art by developing a software tool which enables a system integrator or end-user 
flexibly and efficiently to produce run time software for integration of existing applications in a networked 
environment of heterogeneous computers. In order to achieve this goal, the present invention provides 

45 functionality equivalent to that of a combination of a message and file handling system, a data manipulation 
system, and a local and remote program control system. From the system integrator's viewpoint, the 
present invention provides a message handling system which allows data types and data formats to be 
different at each end of the messaging system, while any changes in data elements, data types or data 
formats of the messages will only require a reconfiguration of the system before start-up. Since reconfigura- 

50 tion is an administrative level activity, the user will not be required to change his or her source code in the 
communicating applications. 

Accordingly, the present invention is specialized for easy modification of data types and data formats 
passed so as to allow transparent communication between data processes of different formats on machines 
of different types. As a result, the application programs which are communicating need not be written in the 

55 same language or be downloaded onto the same computer type. The present invention further allows users 
to link existing applications with minimal or no changes to the code of the applications, thereby reducing the 
amount of custom code that needs to be written, maintained and supported for integrating existing systems. 
The present invention addresses the major integration problems noted in the background portion of this 



4 



BNSDOClD:<EP 0456249A2> 



EP 0 456 249 A2 



specification by providing for local and remote inter-application data transfer whereby existing applications 
may be linked with minimal or no modifications to the applications. Synchronous and asynchronous 
memory-based message transfers and file transfers between applications are also supported. In addition, 
language, data format and data type differences are resolved utilizing data manipulation features such as 
rearranging, adding or deleting fields and converting between data types in accordance with differences in 
hardware, language alignment, and data size. This is accomplished in a preferred embodiment by using a 
Common Data Representation (CDR) for the messages to be transferred between heterogenous nodes. 

The data manipulator (DMM) of the invention provides automatic manipulation of data during run time 
so that two communicating processes can use each other's data without having to change their own data 
models. The data manipulator of the invention takes care of hardware discrepancies, application depen- 
dencies and computer language semantic differences, it can convert one data type to another, restructure a 
message format and assign values to data items. 

Typically, conversion routines are only good for the two machine architectures and/or two languages 
involved. With the addition of any new language or machine architecture to this networked system, a new 
set of routines must be created on all previous machine architectures in the network to support the transfer 
of the data to applications on the new machine or to applications written in the new language. The present 
invention has been designed to minimize the alteration or addition of routines that were written on older 
machine architectures in the network when new machines or languages are added to the system. Also, by 
making the data manipulation module node-specific, it is also possible in accordance with the invention to 
cut down on the number of sets of routines a particular machine might need to send/receive data to/from 
other machines. 

BRIEF DESCRIPTION OF THE DRAWINGS 



The objects and advantages of the invention will become more apparent and more readily appreciated 
from the following detailed description of presently preferred exemplary embodiments of the invention taken 
in conjunction with the accompanying drawings of which: 

FIG. 1 schematically illustrates a prior art Network Computing System (NCS) which allows applications 

running in a distributed environment to share computations as well as data; 

FIG. 2 schematically illustrates the basic components of the integration system in accordance with the 
invention; 

FIG- 3 schematically illustrates how the invention can be used to connect an application to others on the 
same system or to applications that reside on one or more remote systems. 

FIG. 4 schematically illustrates the configuration of the run time components of the integration system in 
accordance with the invention; 

FIG. 5 schematically illustrates the creation of a Data Manipulation Module (DMM) of the invention 
through start-up by the start-up node; 

FIG. 6 schematically illustrates the distribution of the configuration information from the compilation node 

to each of the respective nodes of the same computer architecture as the compilation node; 

FIG. 7 is a flowchart illustrating the procedure for start-up of the integrated system which uses this 

invention; 

FIG. 8 schematically illustrates an example of a heterogeneous networking system in accordance with 
the invention; and 

FIG. 9 illustrates sample configuration files for the sample configuration shown in FIG. 8. 
DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENT 



A system with the above-mentioned beneficial features in accordance with a presently preferred 
exemplary embodiment of the invention will be described below with reference to FIGS. 2-9. It will be 
appreciated by those of ordinary skill in the art that the description given herein with respect to those 
figures is for exemplary purposes only and is not intended in any way to limit the scope of the invention. All 
questions regarding the scope of the invention may be resolved by referring to the appended claims. 

As noted above, present day manufacturing computer systems have often been built from the bottom 
up, thereby resulting in the creation of isolated "islands of automation." For example, the areas of design 
and engineering, manufacturing resource planning, and manufacturing have typically been independently 
automated. As a result, these islands of automation consist of heterogeneous computer systems, operating 
systems, and data base systems. However, manufacturers are now looking for higher levels of efficiency 
and productivity than is available in such prior art systems. Computer Integrated Manufacturing (CIM). the 



EP 0 456 249 A2 



integration of these islands of automation, is a means of achieving such higher levels of efficiency and 
productivity. The preferred embodiment of the present invention is designed for facilitating the development 
of CIM solutions. As will be clear from the following, this is accomplished by integrating existing application 
programs in a networked environment of heterogeneous computers by providing flexible data transfer, 

5 transformation and manipulation mechanisms. 

Generally, the present invention produces run time code that comprises several active programs (or 
software modules) which are used at run time to provide communication between applications on the same 
or different nodes, where a node is any computer in the network's domain. The applications can be on 
different computer systems or on the same computer and may be in the same or different computer 

10 languages. These run time programs handle the data transfer from the source application program to the 
destination application program by transforming the data from the source program into an architectural and 
language independent format using a CDR. For example, the field and record data in the source machine's 
format is converted to the destination machine*s format by first converting to a CDR using locally stored 
routines which convert the internal representation of data on the source machine to the common data 

75 representation format, and after the transfer of the CDR data, the CDR data is converted to the interna! 
representation for data on the destination machine using locally stored routines. In particular, predefined 
links of sources and destinations are called by software modules of the invention to make certain that the 
information is correctly routed from the source to the destination machine. This latter information is called 
the configuration data and corresponds to information provided by the system's integrator concerning the 

20 nodes, processes and possible data manipulations to be performed on the network. 

The system of the invention generally consists of run time and non-run time components. The run time 
components of the invention will be described in more detail with respect to FIGS. 2-4. while the non-run 
time components will be described in more detail below with respect to FIGS. 5 and 6. 

As shown in FIG. 2, the run time components 208 include a data manipulator/translator, a data 

25 transporter, configuration tables and a system manager. As wili be described in more detail below, the data 
manipulator/translator functions to transform data to and from a CDR format acceptable to a given process 
of a specified host computer, while the data transporter functions to pass data in the common data 
representation to/from the network system for sending to a destination application. However, as will be 
noted below, the data transporter also functions to send unmanipulated data to the destination application 

30 when the source and destination applications have the same type and format and hence the message data 
does not need to be manipulated. 

Thus, as shown in FIG. 2. in the system of the invention a plurality of user application programs 202 are 
connected via appiication adaptors 204 using access routines 206 so as to communicate with the run time 
components 208 of the invention. The application adaptors 204 comprise user-written programs which act 

35 as software bridges between the user's application and the system of the invention. In particular, these 
user-written appiication adaptor programs call access routines from an access routine library 206 in order to 
send messages, copy files, control processes, and the like on the network of the invention. These access 
routines 206 are thus used to provide the user with the necessary commands for preparing the application 
adaptor programs. Sample access routines are provided below as an Appendix A hereto, and sample 

40 adaptors are attached as an Appendix B hereto. 

System manager 210 enables a user to administer operation of the system during run time operation. 
For example, the system manager 210 allows the user to access the software of the invention to validate 
configuration, start-up and shut-down the system and perform other system management functions. The 
commartd processor 212. on the other hand, corresponds to a module accessed through the system 

45 manager 210 so as to allow a user to interactively test the messages and links to any process or node 
within the domain of the invention. (As used herein "domain" means the collection of computers that are 
configured to work together in accordance with the invention.) In addition, configuration files 214 contain 
infomnation about the nodes, the structure of the data produced and consumed by the processes, the 
manipulations that must t>e performed on data produced by an application so that it is acceptable by 

50 different processes, and the links binding manipulations to specific languages. Such information is provided 
by the systems integrator before run time and will be discussed in more detail below. The run time 
components are loaded into each node at start-up time using the system manager 210, and these 
components manipulate messages (as necessary) and transport them using the data transporter. The 
manipulations are performed in accordance with data in configuration files 214 held in memory at each 

55 node. Rnally, the data transporter communicates with the network services 216 to pass the message to the 
destination node. 

FiG. 3 shows a system in accordance with the invention where two nodes on a LAN have run time 
integration systems A and B in accordance with the invention for integrating applications 1-4. As shown. 
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each node is loaded with the run time system of the invention (including all elements shown in FIG. 2) for 
allowing the processes 1-4 to communicate even if they have different data types and language formats. In 
FIG. 3, there are various possibilities for communication between the processes shown. For example, 
Application 1 may communicate with Application 2 through the integration System A. Application 1 may 
5 generate data meant for Application 2 in the shared memory of the host computer or in the form of files 
resident on the host disk. This data is picked up by Application Adaptor 1 and passed to Integration System 
A which then gives it to Application Adaptor 2 for passing on to Application 2. Integration System A 
optionally can be instructed to manipulate the data before sending it to Application 2. The data manipulation 
can consist of literal assignments to data, moving data from one structure to another, and translating data 

10 from one structure to another. 

On the other hand, the data may be picked up by Application Adaptor 1 and given to Integration 
System A This data is then sent across the LAN to Integration System B. Application Adaptor 3 is given the 
data by Integration System B which then passes it Application 3 for its use. The user can decide whether 
any necessary data manipulations are done by Integration System A or Integration System B. 

15 FIG 4 shows an implementation of the present invention on a given node 400 of a heterogeneous 
network system during run time. As shown, the integration system of the invention integrates all of the 
user's application programs (processes) 402 which run on the node 400. Applications running on other 
nodes (not shown) are similarly integrated. As noted above with respect to FIG. 2, these application 
programs 402 are respectively given access to the integration system of the invention via access routines 

20 404. which communicate with the integration system of the invention via a library of access routines such as 
those in Appendix A. 

The request manager (RM) 406 maintains a single queue for all user's application program requests so 
that one entry per defined process on node 400 may be read at a given time. The request manager 406 
reads the request from the application program 402 and performs the requested action. Requests can be of 
the following types: reading a message, sending a message, sending a file, starting another process, 
stopping another process, clearing the RM message queue area, recording an error on spooling device 410, 
setting the options for data transfer, deleting a particular message and the like, as apparent from the sample 
access routines In Appendix A. For example, a user's application program 402 may call an access routine 
to send a message to an application program on another node to indicate that a value monitored by the 
application program 402 has changed state. The request manager 406 will then check its configuration 
tables 408 and the request from the application adaptor to see if a data manipulation was requested and is 
necessary for the sending of the message to the remote node. As will be described below with respect to 
FIG 5 the configuration tables 408 will contain Information about all nodes, processes and data manipula- 
tions possible for all message transfers within the network. Accordingly, by determining the source process 
and the destination process of the message request as well as the respective nodes and whether the 
message requested specified a link logical name, the request manager 406 can determine whether the data 
needs to be manipulated for the transfer. The request manager 406 also maintains a message queue 
(memory area) 409 which contains linked lists of data messages for incoming data from other processes. In 
addition, request manager 406 may log user messages to disc 410, If requested, by the sending process. 
Information such as error messages and the like also may be stored for use during system diagnostics. 

When request manager 406 determines that an indicated message needs to be manipulated (i.e.. the 
source message needs to be converted to a different format and/or different language), the request is 
passed to data manipulation module (DMM) 412 where the message Is converted to a common data 
representation (CDR) as will be described below before being sent to the destination node. If the message 
from the application program 402 calls for a transfer of a data file, .the Indicated file is transferred by File 
Transfer Module (FTM) 414 to the destination node. A file message containing file information is sent to 
ONM 416 after a successful file transfer. If the request manager 406 determines that the application 
program Is to send a message to a destination process without manipulation, no manipulation is performed. 
The message data is thus sent directly to Outgoing Network Manager (ONM) 416. ONM 416 receives the 
unmanlpulated message from request manager 406. a message from the File Transfer Module 414 
indicating that a file has been transferred or the message converted to Its common data representation by 
data manipulation module 412 and outputs the message onto the LAN by making a network service call to 
send the message to the destination node. Messages that are specified as "critical" by the sending process 
and which cannot be successfully sent over the network to the destination node are stored (spooled) by 
ONM 416 to disc file 420. Failure to send a message can occur for several reasons including a node or 
network failure or a system shutdown. ONM re-attempts to send a message previously spooled to disc 420 
when the original cause of the failure to send the message has been corrected. 

If the sending process specifies that a message Is to be sent "with-wait". then ONM 416 sends status 
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information to request manager 406's input queue when the message could not be sent to the destination 
node. However, if a message does not have to be manipulated and the destination process resides on the 
same node, then the message is not sent via ONM 416. Instead, the message is placed directly into the 
destination process* message area queue, preventing unnecessary data transmission. If the sending 

5 process specifies that a message is to be sent with "guaranteed delivery", then the request manager 406 
wil! save those received messages in disc file 410 and will delete such messages only if there is a deletion 
request from an application program 402. A read request is typically done by a receiving process before a 
deletion request is done. If a message is not to be sent with guaranteed delivery, then request manager 406 
saves the message in its memory area 409 and the message is available to the receiving process via a read 

10 message request. When the receiving process does a read request, it can specify whether the message is 
to be deleted or not. 

Incoming network manager (INM) 418 receives incoming messages from the network and determines 
whether these messages need to be converted to local format from the common data representation format 
before being sent to the destination application program 402. If such a translation is necessary, as when the 
75 source node was of a different data type or the source programming language was different, the message is 
converted from the common data representation to the local data representation using a library of 
conversion (unmarshalling) routines before the message is sent to the input queue of request manager 406. 
Incoming messages which do not require such manipulation are sent directly to the input queue of the 
request manager 406. 

20 Finally, as noted above with respect to FIG. 2, a system manager 422 is also preferably provided to 
allow the user to administer the system management functions of the integration system of the invention 
during run time. Preferably, a particular node is selected for this purpose. 

The manipulations must take place when an application A having a first language A and data fields of a 
first type is to communicate during run time with an application B having a second language B and data 

25 fields of a second type. In accordance with the manipulation technique of the invention, a Data Definition 
Language (DDL) is used to define the data fields of the application program A and the application program 
B. The data fields of the DDL are then manipulated (rearranged) or the data types are converted by a Data 
Manipulation Language (DML) to that of a Common Data Representation (CDR) having a universal encoding 
scheme such as Abstract Syntax Notation One's (ASN.1) Basic Encoding Rules (BER). The manipulated 

30 data is then converted at the destination node into language B with associated data fields for application B. 
DDL and DML will now be described in more detail. 

The aforementioned Data Definition Language (DDL) is a high level language used in accordance with 
the invention to define the logical structure and types of data used by all application programs on the 
network. More particularly, DDL is used to define data types with declarations in the Data Definition 

35 configuration file (DdeO as will be descrit>ed in more detail below with respect to FIG. 5. Traditional 
languages such as C, FORTRAN, and PASCAL are directly tied to the machine architecture in which they 
are implemented. This is because while different languages may have identical logical data types, those 
data types may be physically represented differently. For example, both C and FORTRAN have muiti- 
dimenskxial array types; however, to store this data type. C uses row-major ordering while FORTRAN uses 

40 column-major ordering. DDL provides a full set of predefined data types that lets the system integrator 
descrifc)e the logical layout of the data used in application programs. In addition to the basic data types in 
most languages. DDL may include an additional data type called "opaque" in accordance with the invention, 
where "opaque" is a custom data type used to describe "type-less" data. 

Data in DDL is defined in a manner roughly equivalent to the type definition in C or the type declaration 

45 in Pascal. DDL declarations in accordance with the invention are similar to the data declarations sections of 
standard languages such as C and PASCAL and hence are believed to be well within the level of skill of 
one of ordinary skill In the art. For example, the DDL of the invention preferably includes information about 
the data types of ail the procedures, and unlike the prior art. the DDL of the present invention allows for 
conversion from one data type to another in accordance with the DML described in more detail below. 

50 Moreover, unlike traditional languages, a DDL definition in accordance with the invention does not bind any 
particular language or machine representation to the data definition. Rather, data definitions and machines 
are linked through a linkage definition as will be described below. Thus, the DDL in accordance with the 
invention is primarily concerned with the logical layout of data, and accordingly, a suitable DDL which 
supports the languages on the network to be integrated is believed to be well within the skill of one of 

55 ordinary skill in the art. By way of example, a partial description of a possible DDL supporting C, FORTRAN 
and Pascal on a network is described in Appendix C. Appendix C aiso includes BNF syntax diagrams for 
DDL declarations in such a case. 

Data Manipulation Language (DML) as used herein is a high-level language that is used to manipulate 
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data. After the data types are defined in DDL (in Ddef), the manipulations that must be performed on that 
data are defined in the Data manipulation definition configuration file (Dman) using DML as will be described 
below with respect to FIG. 5. The data manipulation declarations can be either assignment statements or 
move statements. Assignment statements set default values for destination structures, while move state- 

5 ments move the source data structure to the destination data structure, correcting for differences in 
languages and machine architectures, and providing type conversions where necessary. These type 
conversions may be performed on boolean, integer, floating point and ASCII fields. 

As an example of a DML in accordance with the invention, a DML is described in Appendix D for a 
network have a DDL supporting C. FORTRAN and Pascal. Appendix D also includes BNF Syntax diagrams 

70 for DML definitions In such a case. One skilled in the art will appreciate that the DML described in Appendix 
D is for a specific embodiment and may be readily modified by one skilled in the art in accordance with the 
general principles set forth herein. 

SETUP PROCEDURES 

75 

FIGS. 5-7 illustrate the procedure for starting the system and setting up the DMM run time module 
described above with respect to FIG. 4. However, before describing these figures, the basic steps in the 
task of integration analysis that a system integrator or end user would follow in accordance with the system 
of the invention will be described. During the process, the system integrator completes a high level design 

20 of the integration system of the invention by determining the number and general functions of the processes 
needed to fulfill defined functional requirements. This information is required in both configuring the system 
and developing the application adaptors for it. 

Basically, configuring the system of the invention consists of creating with any text editor a set of 
configuration files that describes the data to be transported and the operating environment. The configura- 

25 tion files provide information about the data such as the way it is structured, how to access it. how to 
manipulate it. and how to display It They describe the operating environment by defining the computers in 
the network, their links, and the types of processes. The configuration fields are formed by the system 
integrator or end user in accordance with the following steps. 



30 1. The Functional Requirements Analysis. 

Functional requirements analysis means clearly defining the environment in which integration by the 
invention is to be performed so that" the systems integrator can do a high-level design of the system to be 
integrated. In other words, the user determines what is to be accomplished by integration so that the 

35 requirements of such integration can be specified in a programmatic interface development phase. For 
example, the user may want several applications that manage part of a manufacturing system, such as 
tracking and scheduling work orders, to be able to communicate and exchange data. The user will need to 
know the resources, namely, the applications that perform particular functions or processes, the machine 
nodes on which those applications reside (i.e., logical node name, machine type, physical node name, and 

40 so forth), and network characteristics. Such network information is stored in a network definition (Netw) 
configuration file. 



2. Data Flow and Application Analysis 

45 The user must also analyze the types of data and the movement of the data between the applications 
that will be integrated. The user also will need to identify any synchronization needed to control the flow of 
data or to insure that the data remains consistent. Whether the data flows between different applications on 
the same system or between applications on different systems, the user also must know the specifics of the 
data being moved between applications. For example, the user must know the structure of messages and 

50 source applications sent and what format the destination application will accept. The user must also know 
the programming language used to produce the source message and what language will be used to read 
the messages at the destination. If manipulations are necessary to transform the message data into a format 
acceptable by the receiving application, the user will form a Data Definition file (Ddef) written in DDL and a 
Data Manipulation file (Dman) written in DML The Ddef file defines the format of the messages passed 

55 between applications, specifically, the integers, strings, arrays, structures, records and bytes that make up 
the output of one application and the input for another application. The Dman file, on the other hand, 
contains the definitions of each data manipulation as described above. Each data manipulation defines the 
operations that must be performed on a source data structure so that it has the format and typing that the 
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destination application can accept. 

3. Designing The Processes 

5 The user designs the integrated system of the invention by deternnining the tasks or processes required 

by the flow of data. The user also determines how these tasks should be grouped in application adaptors 
and stores this information in the Process Definition configuration file (Proc). Information in the Proc file lists 
the processes that send and receive data, default runstrings and miscellaneous execution information. The 
process logical name is used by the access routines (Appendix A) to reference a particular process 

10 definition entry, 

4. Determining Data Format 

The user also determines whether the data exchanged is in file or message format. If it is in file format, 
T5 the user determines what file copy options to use. This information should be stored in a File Definition file 
(Fdef). If it is in message format, it should determine what manipulations and the like are needed. 

5. Setting Links 

20 Finally, the user defines links to associate data definitions and data manipulations with the list of nodes 
where the source data may be produced and the source and destination languages of the data transferred. 
This information is stored in a Link Definition configuration file (Link). The Link file describes the physical 
characteristics of data at the source and the destination of a message and bind specific data or 
manipulation definitions to particular links. The Link definition binds data definitions and manipulations to 

25 source locations and architecture types, source and destination languages and file definitions. 

Thus, configuration in accordance with the invention means describing the applications^ nodes in the 
network, processes, files, links and manipulations to the integration device of the invention. This is the 
information gathering process. In a preferred embodiment of the invention, six configuration files 502 (FIG. 
5) are created by a text editor to model the system to be integrated in accordance with the invention. 

30 Once these configuration files are created and validated, the system of the invention is ready for start- 
up. In particular, the run time system of the invention as shown in FIG. 4 must be established on each node 
of the network so that the processes on each of the nodes within the network may communicate with each 
other as specified in the configuration files. In other words, the Df^M modules of the invention as shown in 
FIG. 4 must be made node-specific and installed on all the nodes in the integration domain and the 

35 configuration tables 408 loaded into memory. However, before this is done, the integrator designates an 
administration node, for providing functions such as start-up, shut-down and security, and preferably, a 
given number of alternate administration nodes are also established in case of failure of the primary 
administration node. The system manager 422 is then used to configure system security and to perform 
startup as will be described below. The user then writes and compiles the application adaptors for the 

4o various processes. However, since the application adaptors require configuration information, configuration 
and application adaptor development can be done in conjunction or in any order. On the other hand, since 
the user may use the command processor to simulate other adaptors for testing purposes, it is preferable 
that the user perform adaptor development as a final step. The user is now ready to start running the 
system of the invention to generate the DMM modules as shown in FIG. 5. 

45 As shown in FIG. 5. the configuration files 502 are loaded onto the administration node. A validation 
program 504 reads in the network definitions (Netw), the process definitions (Proc). the link definitions (Link) 
and file definitions (FdeO from the configuration files 502. The configuration files 502 must reside in a 
directory identified to validation program 504. Validation program 504 checks the integrity of the configura- 
tion files and converts them into the binary data files 510 required at start-up. The validation program then 

50 invokes the DDL compiler 506 to read the data definition (Ddef) and produce a DDL symbol table in 
memory. The DML compiler 508 is then invoked by the validation program 504 to read the data 
manipulation definitions in the Oman file and to generate C source files 512 which contain the 0 language 
instructions to perform the data manipulation and conversion of the source data to a common data 
representation. The DML compiler 508 then uses data definition information for the DML compiler 508. link 

55 definitions from validation process 504 and manipulation definitions from Dman 502 to generate the look-up 
table C source files 530. the manipulation C source files 512, and the C source index files 514. The C 
source index files contain the list of all C sources generated for the various nodes in the domain. A different 
source file index is generated for each machine type. 
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The validated configuration files 510, the manipulation C source flies 512, and C source index files 514 
and look-up table C source files 530 thus represent the configuration information in a manner that can be 
loaded into memory but is instead used to build the DMM 412. These files are used by the administration 
node during start-up process 516 to create Configuration Tables which are distributed to all nodes in the 

5 integration domain. The C source index files 514. lookup table C source files 530. and manipulation C 
source files 512 are used in forming node-specific data manipulation modules. 

In particular, start-up is initiated on the administration node by invoking the DDLOAD program 518 to 
load the Configuration Tables into memory. The Configuration Tables include (1) a list of nodes in the 
integration domain and (2) a list of compilation nodes, where a compilation node is defined as a node on 

70 which the integration system compiles the look-up table C source files 530 and the manipulation C source 
files 512 for all nodes belonging to that computer architecture family in order to create the node-specific 
DMM. There must be at least one node defined as the compilation node for each type of computer 
architecture in the integration domain. In other words, a compilation node is provided for each type of 
computer architecture within a heterogeneous computer network environment. Of course, for a homo- 

75 geneous computer network environment, only one compilation node is required. 

Once the Configuration Tables are loaded on the administration node during start-up, start-up process 
516 marks the nodes to be started and asks the system manager to schedule the DMM builder 520 on each 
compilation node. As noted above, there must be a compilation node for each machine type in the system. 
If the compilation node for a particular machine type is not found, an error message is issued and start-up 

20 is halted on all nodes of that machine type. 

At each compilation node, the following start-up activities are conducted by DMM builder 520. The 
DMM builder 520 pulls (copies) the C source index file for its particular machine type along with the 
relevant C sources (look-up and manipulation) and the list of nodes within the network that need a new 
DMM onto the compilation node and compiles the C source files into object modules. The result is a DMM 

25 module 528 on the compilation node which corresponds to the DMM 412 used on that node during run time 
as shown in FIG. 4. The C compiler 524 compiles the manipulation C source files 512 into a customized 
library of object files 526 which is specific to that machine or architecture type. The Compiler 524 compiles 
the look-up table C source files 530 into node specific object files. 

The compilation node then distributes the node-specific DMM module 528 to each node of its machine 

30 type on the network that needs it. FIG. 6 shows how the compilation node distributes the DMMs to all such 
nodes. As shown, the validated configuration files 510. the look-up C source files 530. the manipulation C 
source files 512 and the C source index files 514 are pulled by (copied) the compilation node for forming an 
architecture specific DMM module 528 as just described. This DMM module 528 is then distributed to all 
other nodes (nodes 3-6) of that architectural type on the network which need a DMM, and these nodes, in 

35 turn, notify the compilation node that they have received the DMM. The compilation node passes this status 
to the start-up process. 

In summary, the process performs the following activities on each node, beginning with the start-up 
node: copies the validated files to the node; loads the Configuration Tables into memory; prepares the run 
time programs for start-up; starts/stops the run time programs according to the user's decision; copies a set 

40 of configuration files to all alternate administration nodes; and copies the Manipulation C source files 512, 
the lookup files 530 and the C source index files 514 to all alternate administration nodes, 

FIG. 7 is a summary of the procedure for setting up and starting the integration system of the invention. 
As shown, the user first configures and validates the integration at step 702 and then determines at step 
704 whether application adaptor programs need to be created or modified in order to interface the 

45 application program to the integration system. If so, the application adaptor programs are created or 
modified at step 706 and then compiled at step 708 for linkage into the system at start-up (step 710). The 
user may then test the configuration at step 712 using the command processor, and if the configuration has 
no problems, all nodes may be started up. On the other hand, if there is a problem with start-up, at step 
714 It is determined whether the configuration needs to be changed. If not, the application adaptor 

50 programs are modified at step 716, and the modified adaptor programs are then compiled at step 708 and 
once again linked into the system for start-up at step 710. However, if the configuration does need to be 
changed after testing, control branches from step 714 to step 718 where the system is shut down to allow 
for reconfiguration and validation of the Configuration Tables 408. Thus, in the presently preferred 
embodiment, the system is shut down for reconfiguration since the configuration data is linked in during 

55 start-up of the nodes. However, as will be apparent to one of ordinary skill in the art, the configuration may 
be changed and validated during run time without shutting down the system, but it cannot be switched into 
the running system unless the current system is shut down. Once the integrated system is running, control 
may be turned over to the system administrator for daily administrative tasks. 
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DMM RUN TIME OPERATION 



As described with respect to FIG. 5, the data manipulator of the invention preferably comprises a DDL 
compiler which processes data declarations and generates symbol tables for use by other software modules 

5 of the data manipulator. A DML compiler is also provided for processing data manipulation statements 
defined by the users and for generating C source code modules that will "be compiled with data encoding 
functions (such as ASN.1 Basic Encoding Rules) in a Common Data Representation Library and with data 
conversion and manipulation functions in a Data Manipulation Library, The object code modules created 
after the compilation will be executed at run time by a module called the data manipulation shell, which 

10 determines what type of manipulations are required for a specific message and invokes appropriate 
manipulation modules generated by the DML compiler to transform data into a common data representation 
notation for transmission to a computer with a different architecture. Finally, the data manipulator of a 
preferred embodiment of the invention will include an "unmarshaller" module which is invoked by the 
Incoming Network Manager 318 to decode a message in common data representation format to the local 

75 host data and language representation. 

During operation of the data manipulation module, the data manipulation shell reads a message from its 
in-coming mailbox (from request manager 306) and calls appropriate data manipulations (such as those in 
pseudocode form in Appendix E) to transform the data as requested by the user's application program (i.e., 
to match the destination format). After the message is manipulated, the data manipulation shell sends it to 

20 the Outgoing Network Manager 316 for delivery. At the receiving node, the Incoming Network Manager 318 
gets the message from the network and determines whether an unmarshalling task (such as those in 
pseudocode from in Appendix F) is necessary. If it is, the incoming network manager 318 invokes the 
unmarshaller module. From the message content, the unmarshaller module determines which functions are 
needed and invokes these functions to perform the unmarshalling. 

25 As noted above, the objective of the data manipulation module is to enable the user to transfer data 
between two applications residing on different machine architectures and written in different languages. The 
problem which arises when this is attempted is that the sending and receiving machine 
architecture/language may emit or expect the data to be in a particular representation or a particular data 
size or alignment. For example, string representations, boolean representations, row/column major address- 

30 ing. data size and the like may be language specific, while byte order, two's complement notation, floating 
point (real) representation, character set, data size and the like may be machine-specific. Such differences 
in architectures and languages imply that some sort of data manipulation must be performed on data 
emitted to make it acceptable to a receiving* application. Conversion routines are needed to support this 
data manipulation, and such conversion routines are included within the data manipulation module of the 

35 Invention as described above with respect to FIGS. 5 and 6, 

The present invention uses a Common Data Representation (CDR) in which the conversion routines 
needed are written to convert data back and forth from a local machine and language format to a machine- 
and language- independent data format. Thus, a sender of data will convert the data into CDR format and 
send the data. A receiving system will invoke routines to convert the CDR-formatted data into the receiving 

4o system's local data format- Each machine architecture thereby only has to know about how to convert from 
its local machine format to CDR. Moreover, any new machine architecture added to the network only has to 
know the same for its data converting. 

In accordance with the invention, one skilled in the art may design his or her own common data 
representation which will handle all the data types which are to be supported on the network. However, a 

45 presently preferred embodiment of the present invention uses an already existing, standard CDR encoding 
rules entitled OSI ASN.1 Basic Encoding Rules (BER). In particular, a preferred embodiment of the invention 
uses the byte-level "transfer syntax" format specified in ASN.1 for CDR encoding the data described by the 
data definition and data manipulation languages previously described. 

Thus, in accordance with a preferred embodiment of the invention, the data elements transferred 

50 between machines are in ASN.I BER encoding. The problem here is that when an ASN.1 -encoded data 
element arrives on a target system, that data element could be unmarshalled into any one of a number of 
language- specific data types. Thus, a "type attribute ID" must accompany the ASN.l encoded user data 
element in the message to identify the language-specific data type that the ASN.1 -encoded user data 
element will be unmarshalled into on the target system. These type attribute IDs are also in ASN.1 

55 encoding. A mapping is needed between DDL types and ASN.1 data types. The following is a table of 
presently preferred DDL data types versus ASN.1 encoded data types: 
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DDL Types 


Type AUrioute llf 


ASN.l Types 


Type Attributes 


bit_field 


OlT_rIbi-L) (U) 


Diismne 




byte (8-biO 


BYTE(l) 


integer 


shorcjnt 




mteeer 


US 1 tOCK \^) 


lone-.int 


T /^Ki/^ Tj^rr (A\ 


short.boolean 


SriORT.BOOLcAiN [j) 


boolean 


boolean 


oUULcAiN (0) 


lon^_boolean 


T r\sif\ xir\r\\ caisJ 7''7\ 


cnar (8-Dit) 




Strine 


opaque (S-bit-alicncd) 




octet strine 


real 


REAL (10) 


real 


Icnc^rcal 


LONG.REAL (11) 


strine f8-bit chars) 


STRING (12) 


strine 


max leneth 


unsiened bir.field 


LLBuinELD (13) 


bitstrin^ 




unsiened oyte (o-oit; 




integer 


unsiened shortjnt 


U.SHORT.INT (15) 


unsiened integer 


U_INTEGER (16) 


unsiened lone-int 


U_LONG_INT (17) 


mulriple-dimen array* 


ARRAY (18) 


sequence -of 


record 


RECORD (19) 


sequence 


restrictive type 


packed muUiple-dimen array* 


PACKED.ARRAY (20) 


sequence-of 




packed record 


PACKED.RECORD (21) 


sequence 


restrictive type 



TABLE 1 

*The unmarshalling module assumes that the code doing the 
marshalling will place th'fe elements of the multiple-dimensioned 
array into the row-/column-ma jor order for the target language • 
In other words, the unmarshaller assumes that the elements of the 
ASN.l array are in the proper row-/col^ri-major order for the 
target language. It does NOT do reordering of array elements. 

The parenthesized ( ) ntimbers after the type attribute ID name 
indicate the numerical value of the type attribute ID that will be 
used in the code. 



As shown in Table 1 , the type attribute ID is a name identifying the target DDL type of the ASN.1 type. 
The number after the name is used in the source code to represent that ID. Besides the type attribute IDs, 
the type attributes also include extra information that is transferred with the ASN.l data type to allow for the 
correct unmarshalling by the receiving node into the target DDL type. ASN.1 data type format does not 
have a place for such information. For example, the ASN.1 string type data element has a field to indicate 
the current size of the string value, but no field to indicate what the maximum size of the string can be. This 
maximum size information is type attribute information. Because both the type attribute IDs and type 
attributes are extra information needed in addition to the actual ASN.1 encoded user data, they have both 
been conceptually lumped together under the title of "type attributes" herein. 

"Marshalling" of data involves converting data in a local format into a machine and language 
independent CDR format as described above. Such marshalled data can then be sent to an "unmarshalling" 
module resident on this or another system in the network. The unmarshalling module will then convert that 
data into the local machine- and language- dependent format. In accordance with the invention, a 
marshalled message is broken down into two main parts: a static format message header and a dynamic 
format application data part. The division of these parts is based on whether the part contains predefined, 
static format data, or whether it contains application-bound data that can have any type of format. The 
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message header contains administrative information needed to transfer the message, such as 
source/destination node names, operation flags, target process logical names and the like, it also contains 
the information necessary to carry out the specific functions such as send a file, start/stop a process, return 
status to the machine application server, and the like. The dynamic format part, on the other hand, varies 
5 depending on the application data being transferred. 

The dynamic part of the message contains significant subfields. These are shown as follows: 



Static Message Part 
Data Buffer Header/User Data/Type Attributes 



75 The data buffer header contains information needed to initialize the unmarshalling process, while the 
user data is the ASN.1 encoded "pure" data that is expected by the receiving application. Type attributes, 
on the other hand, are e>ctra. non-ASN.1 information needed to help unmarshall the user data. For example, 
this type attribute data will be node specific information which allows the user data to be converted to the 
local data format type. Preferably, the user data is kept in one buffer and the type attribute data is 

20 contained in another data buffer during marshalling to facilitate appending (copying) of the type attribute 
data for a given primitive to the associated user data. The data buffer header, on the other hand, may 
contain information such as at what offset do the type attributes start and what is their total length. Detailed 
examples of the implementation of marshalling with this type of buffer format can be found in Appendix E. 
The user data will be marshalled into ASN.1 data elements according to the DDL-type/ASN.1-type table 

25 given previously and the ASN.1 Basic Encoding Rules (BER). 

The data manipulation module marshalis the data in accordance with the invention by building a library 
called a (Vlarshalling Routines Library (MRL). Each MRL will be customized for the particular machine 
architecture. Thus, there will be one MRL version per machine architecture type supported. In a preferred 
embodiment, the MRL assumes that it will be called by C language code compiled by a C compiler 

30 supported by the integration system for that particular computer architecture. Also, the MRL is not designed 
to be a run time shared library, and instead, the library code will be linked Into the DMM's code at link time 
as described above. 

Code emitted by the DML compiler 508 will do the following marshalling steps: 
1 . Start the marshalling process by marshalling the header; 

35 2. Marshalling the source data elements in the sequential order that they will appear in the buffer at the 
destination program; and 

3. When finished marshalling all data elements, marshalling the trailer (if present). For ease of use, the 
marshalling routines preferably provide two buffers, a source buffer for holding the source localized data 
element, and another buffer, the target buffer, for holding the marshalled data elements. 
40 The "unmarshalling" routines of the invention will now be described. Unmarshalling Is the process by 
which data in the machine-independent CDR format is converted into some target machine and language 
format. The type of information used by the unmarshalling routines is of two types. The first type is 
information that can change with the use of the data such as signed/unsigned, packed/not packed, and the 
like. This information will be passed with the data In the CDR data stream as type attributes. The other type 
45 of information Is stable information such as data alignment and byte/word sizes. This Information may fit 
naturally into static tables. 

As each CDR data element is being read, it Is unmarshalled using unmarshalling routines which are 
built into a library called the Unmarshalling Routines Library (URL). As with the MRLs, each URL will be 
customized for a particular machine architecture. Thus, there will be one URL version per machine 

50 architecture type supported. Much of this customization can be handled through changes In values as the 
Library is built. As with the MRL. the URL is not designed to be a run time shared library. Rather, the library 
code will be linked into the INM's code at link time. 

A selective low-level routine will be invoked to unmarshall a corresponding data element. The decision 
of wtiich low-level routine to invoke will be based on what type of CDR data is in the CDR data stream. 

55 Thus, there must be a main routine built on top of these low-level routines that will look at the next data 
element in the CDR stream and use the type attribute ID of ihat element to select the low-level 
unmarshalling routine to invoke. Such a routine is straightforward and may be readily designed by one 
skilled in the art. 
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Language-specific information about data type sizes and alignments and pointers to the conversion 
routines to invoke for the DDL type at the destination node are organized Into a 2 x 2 matrix called a 
Language Table. There is one Language Table per language per machine type. Preferably, the rows are 
DDL types, while the columns are the related localized data element size, alignment and pointer to the 
specific DDL unmarshalling routine to call: 



TO 



15 



DDL Type j 


sac 1 


Aligament 


marshalliogroutif 


char 


2 


2 


ptr 


int 


4 


2 


P» 


rul 


8 


8 


ptr 


uodgined int 


4 


2 


ptr 



20 



cdr^to.ujnt (aze, ilignmcat); 

TABLE 2 



25 



In order to determine which Language Table to choose upon receipt of data, the header of the CDR is 
examined for a byte of information that selects what the target language will be. This byte is used to set a 
global pointer to point to the Language Table to be used to unmarshall that message. To go from this byte 
value to a global pointer can be done with the following table of pointers to Language Tables: 



30 



35 



40 



aouroe.buffer 
header 



which Jaaguage 



incex 



45 




TABLE 3 

50 The Language Table Pointer Table (ltp_table) is set up when the unmarshalling code starts up. During 
the start of unmarshalling a message, the target language byte value is used as an index into ltp_table to 
retrieve a pointer to a Language Table. A global pointer is set to point to this Language Table, which is used 
by the unmarshalling code to convert the remainder of the message. 

It would be easy enough to have a global pointer pointing to the selected Language Table. However, a 

55 problem arises with Pascal and packed data types. Namely, a CDR of a message arriving on a system with 
a target language of Pascal may have a mix of packed and unpacked data elements. Each packed versus 
unpacked data type requires its own size and alignment information in the Pascal Language Table. Thus, 
the Pascal Language Table would have tr contain double the amount of information of the other Language 
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30 



Tables. This would also require special checking to handle packed data elennents since colunnn indexes into 
the Pascal Language Table would have to be different to access the extra information for packed 
sizes/alignments for data elements. Since it is desired to minimize the amount of special handling and 
checking for Pascal packed types, the packed Pascal may be treated as if it resided In another Language 
Table. Then, by providing a semi-transparent mechanism for dynamically accessing between either the 
packed or unpacked versions of the Pascal Language Table, the code will be able to run much smoother 
and faster. The existence of the extra packed Pascal Language Table should also not affect how other 
languages' Language Tables are accessed. The Itp table proposed looks like the following: 



10 



IS 



20 



25 



iDdex 



Poiater Table 



C 
Poftns 




TABLE 4 



The byte out of the header of the source buffer is used as an Index Into the Itp ^table as shown in 

35 Table 4. This index is saved in a global variable; therefore, with this index, one knows which target language 
will be unmarshalled to. Also, the entry the index selects contains two pointers- one to a packed version of 
the Language Table, and another to an unpacked version of the Language Table. This only applies to the 
Pascal entry in ltp_table: the other languages have a NULL pointer for the packed pointer. 

When the unmarshalling process comes across a packed array/record type attribute ID (Pascal must be 

40 the target language), this type attribute is immediately placed in a stack frame. The rest of the fields in the 
stack frame are initialized accordingly from information accompanying the type attribute ID. The unmarshal- 
ling process continues parsing by looking at the next data element in the input buffer. 

However, the data element's size, alignment, and pointer to the conversion routine to invoke must also 
be determined, for although an index to the Itp ^table is available, the question becomes which pointer 

45 (column) should t^e used in that row. This decision depends on whether the previous stack frame was 

packed or not The corresponding value is used as the index into the selected row of the Itp table. The 

type attribute ID is used as an index into the Language Table to pick up at a particular row the parameters 
and pointer to the routine to invoke. 

As noted above, the user data in the transmitted message is encoded using ASN.1 BER, This is not 

50 enough for the receiving side to unmarshall this data into target language data types, for the type attributes 
and data headers are also marshalled although needed to help in the description. In other words, since all 
parts of the message follow the ASN.1 Basic Encoding Rules, the other parts must be decoded without the 
benefit of the data buffer header and type attributes. This is handled by expecting the data buffer header 
fields to be in a particular order for the data buffer header. Thus, by appropriately placing the data fields, 

55 ASN.1 unmarshalling routines may be called to unmarshall the data containing the version and target 
language data. However, the order of the type attributes field cannot be predicted. Accordingly, the type 
attributes may be unmarshalled on-the-fly during run time as needed. 

Since homogenous data is not marshalled in accordance with the invention, INfy^ 418 must have some 
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mechanism for determining whether a received message has been converted to the CDR. Generally, this 
may be accomplished in accordance with the invention by providing a flag in the received data which 
Indicates whether marshalling has been conducted at the sending side. Preferably, the following data 
transmission sequence is used to ensure that INM 418 will recognize whether the received data is in CDR 
5 form. 

In particular, on the sending side data from the source application progrann gets manipulated and 
marshalled by DMM 412. DMM 412 sets a flag bit to indicate that the dynamic part of the message has 
been marshalled. DMM then sends the message to the ONM 416 on the local node. ONM 416 places a field 
containing the size of the total message in front of the message to be sent. The message is then sent to the 
10 destination node. 

On the receiving side. INM 418 receives the incoming messages and first reads from the network the 
total size of a message being received. Then INM reads in the number of bytes specified by the total size 
to obtain the entire message. At the next step, INM 418 looks at the flag field of the message header, and if 
the "marshall" flag bit in the flag field is set, then the dynamic part of the message is unmarshalled into a 
75 new buffer using a special unmarshalling routine, if the "marshal!" flag bit is not set. however, this step is 
bypassed and the received data is sent directly to the input queue of the request manager 406. In this 
manner, the request manger 406 will be certain to receive data having the proper formatting for the 
destination application. 

20 SAMPLE CONFIGURATION 

As noted above, before one can configure an integration system in accordance with the invention, one 
must have complete understanding of the system requirements, the system and application capabilities, and 
the integration functions required by the applications. Such information includes (1) the applications that will 
25 be served by the integration system, (2) the data flow (linkage requirements) between those applications. 
(3) the machine types running the applications, and (4) the type of networking used to tie the systems 
together. This information must be supplied to configure the integration system in the manner set forth 
above. 

The following example describes the integration tasks using one portion of a computer-integrated 
30 manufacturing system which manages work orders. The example wiil be described with respect to FIGS 8 
and 9, where FIG. 8 shows the system to be integrated and FIG. 9 shows the resulting configuration files. In 
the example, there are three applications handling work orders: a material resource planner (MRP) which 
generates work orders and operates on an HP9000/S800 computer (CPU1); a scheduler (SCH) which 
schedules the work and operates on a HP9000/S800 computer (CPU2); and a cell controller (CTL) which 
35 which manages the work and reports work completed and operates on an HP90000/S3000 computer 
(CPUS). These applications are connected over a LAN as shown in FIG. 8. For this example, it wiil be 
assumed that the MRP application generates work orders and keeps track of work completed and is written 
in C programming language, while the SCH application contains information about the machines, people 
and resources available to work on orders, creates schedules for the work, and is also written in the C 
40 programming language. The CTL application manages the work and is written in FORTRAN. 
The configuration files for the system are formed as follows: 

Network analysis provides information about each of the nodes which must be known before they can 
be used in the integrated system of the invention. This information is used in the Network Definition File 
(Netw) to define the nodes in the integration system. As shown in FIG. 9, the network definition file includes 

45 a file entry for each node in the integration system on which at least one application runs. In this example, 
the network definition file preferably describes the following items for each node: its logical name and 
machine type, whether or not it starts at system start-up, whether or not it is the compilation node, the 
maximum number of clone processes it can have, its maximum message area size, the maximum 
percentage of the message area any single process may use, its network type, and its physical node name. 

50 For example, application MRP runs on a node having a logical node name CPU1 and a machine type 
HP90000/S800, is designated to start at start-up. is not a compilation node, and is connected to a LAN type 
network. Netw contains similar information for the other nodes except that they are compilation nodes. 

Data flow analysis of the system is then performed to determine the^path that message data takes from 
a source application to a destination application. In particular, the user determines what each application 

55 expects as data, what each application that needs to transmit data produces as data, and how the data is 
represented and accessed in each application. The portions of the data that will be sent between 
applications is also determined. In the example, the format and type of data that is exchanged by the three 
applications in the work order management system are determined. It will be assumed that the applications 
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exchange data in both files and message packets. 

Because the data in the example is exchanged between applications written in different languages, the 
user is required to define the types of the data when the system is configured. These data descriptions are 
formed In the Data Definition File (Ddef) which, as noted above, enables messages to be in different formats 
5 or applications to be transformed in different languages at the source application and at the destination 
application to be transformed by using the data definitions in the Ddef file and the manipulations in the 
Dman file. On the other hand, if the data is in file format, the user can specify the options of the file transfer 
in a File Definition File (Fdef). 

By way of example, application MRP may transfer a work order file to application SCH containing a 
70 work order number, a parts number, quantity information and due dates. The application MRP may also 
receive completion messages from application CTL after manufacturing is complete. Also, since the 
destination message layout is different from that of the source, a data manipulation must be defined with 
this message transfer. 

Application SCH may transfer instructions in a file for scheduling work from the MRP program and 
75 dispatch a message to the CTL application containing: part number, quantity information, start date, start 
time, stop date, stop time and work order number. Once again, because the destination message layout is 
different from that of the source, a data manipulation must be defined for this message transfer. Also, 
completion messages from the CTL program after manufacturing is complete may be received by the 
application SCH. Moreover, since the source and destination applications are in different languages, a link to 
20 correct for representational differences between the languages must be identified. 

The CTL application receives dispatched messages from application SCH including: the work order 
number, the part number, the quantity information, the start data and the start time. Work order completion 
messages may ttien be sent to the application MRP, such messages including: work order number, quantity 
information, part number, completion date and quality information. Also, a work order completion message 
25 containing the work order numtjer, the quantity, the part number and completion date may be sent to 
application SCH. 

At the data flow level, the number of processes the system data transfers require, or the specific tasks 
of those processes varies from one design to another. However, the information gathering procedures and 
mapping to configuration remain the same. For the example, the process configuration files are shown in 

30 FIG. 9 where the MRP application requires a process MRPOICP to send out the work order file and a 
process MRP02CP to receive completion information. The SCH application also requires two processes: 
SCH01CP to receive the work order file and SCH02CP to send out a dispatch message and receive a work 
order completion message. The CTL application, on the other hand, requires only one process: CTL01FP to 
receive the dispatch message and send out completion messages. Thus, five processes are necessary to 

05 transfer the data between the three applications, and two manipulations (MANiPl and MANIP3) are required 
because the layout of the data at a destination application is different from the data layout at a source 
application due to language and machine differences. The process Information is stored in the Proc file, 
while the manipulation information is stored in the Dman file as shown in FIG. 9. 

Since the work order management example given primarily exchanges messages, the file definition 

40 configuration file (Fdef) contains only FILEDEF1 for the case in which the MRP application sends a work 
order file to the SCH application. When the file reaches the SCH application, it will replace the existing 
target file. 

The next step in the integration process requires that the language and structural details of the 
application data be identified. Once the data structure of both the source and destination applications have 

45 been identified, the user can decide on the manipulations required to transform the source data structure to 
the destination structure and data types. This data information goes into the data definition file (Ddef) and 
data manipulation file (Dman). Thus, the user must know the sizes of the exchanged data so that the 
corresponding DDL data types may be used to define the data in the Ddef file. The following Table 5 shows 
how data sizes in the dispatched message are used to correspond to data types between C and DDL and 

50 between FORTRAN and DDL: 
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Source 



Language: C 

Sending Buffer Dispatch message at SCHED 



C structure 


DDL data deflnitioo 






Name: disp^c 




char 


part_no[17] 


part_no 


:siring(17] 


int 


qty 


qty 


: integer 


char 


start_datc(71 


start_datc 


:slring[7J 


char 


start_tinic(5] 


start^time 


:5lring[51 


char 


stop_daic[7] 


stop^date 


:string{7] 


char 


stop_lin3e{5] 


$top_time 


:string{5] 


char 


wo_no[ll] 


wo^no 


:string(n] 



Destination 



Language: FORTRAN 

Receiving Buffer. Dispatch message at CTL 



FORTRAN DDL data deflniUoQ 

Name: disp_f 



part.no : string(li5] 

• • S€e below wo^no : string[10] 

far FORTRAN qty : integer 

definitions start.daie :striDg[6] 

start_time : stnng{4] 

stop.date : stxingI6] 

stop.timc : striDg(4] 



TABLE 5 



25 The information from Table 5 may be used to determine the manipulation pattern necessary to transform 
the data in the Integration system. These manipulations go into the data manipulation file Dman. For the 
present example, the manipulation statement that is required is a MOVE of the source structure (Disp^c) to 
the destination structure (Disp_f) (i.e.. MOVE disp_c TO disp_f). This manipulation statement is contained 
in the example manipulation called Manipl. 
30 The user is now ready to describe the nodes where the source data defined in the DDL or DML can 
originate. This information is stored in the Link Definition File (Link). The links bind the source and 
destination language types to a specific data definition or data manipulation at validation. At run time, the 
Link file designates the distribution' of node-specific data manipulations to the appropriate nodes. For 
example, Link1 requires Manipl to convert from source language 0 to destination language FORTRAN for a 
35 message originating at source node CPU2 and destined for node CPU3. 

For the example given in FIGS. 8 and 9, the Link file defines the four links required for the work order 
management system example, Link1 binds Manipl (the manipulation performed on the dispatch message 
sent from SCH to CTL) to the G language used by the SCH application. Link2 on the other hand, corrects 
for representational differences in the work order complete message sent from the FORTRAN application 
40 CTL to the C application SCH. The message has the same record format but is in a different language. 
Link2 thus points to the DDL definition of the source data structure (wo_comp_f) in the Ddef file. Link3 
binds Manip3 (the manipulation performed on the work order complete message sent from CTL to MRP) to 
the FORTRAN language used by the CTL application. Finally. Link1 defines the link for a file transfer. The 
file transfered. filedefl, is the work order file that the MRP application sends to the SCH application. The 
45 NULL value indicates that no manipulations are required, only specification of destination file attnbutes. 
CPU2 and CPUS receive the DMM modules (at startup) that enable them to handle the transfers. 

FIG. 9 shows the configuration files as created for the work order management system example 
described above and shows how information defined in each file is referenced by the other files. This 
configuration file set is validated before it is used in startup in the manner described above with respect to 
50 FIG 5 Thus, DMM 412 is created specifically to handle the manipulation specified by the user m the 
configuration files. For this purpose, these files are validated before startup and loaded (at startup) on each 
node as Configuration Tables as previously described. 

Although an exemplary embodiment of the invention has been described in detail above, those skilled in 
the art will readily appreciate that many additional modifications are possible in the exemplary embodiment 
56 without materially departing from the novel teachings and advantages of the invention. For example, access 
to a remote database using the invention may be possible by eliminating the dependencies on a specific 
set of database management system calls. Thus, an application accessing another application's database 
through the remote data access routines will be freed from changes should the database structure or the 
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database management system used by the target application change. This can be accomplished through 
the syntactical and structural definition of the target application database in the configuration files. In 
addition, the configuration files of the invention may have domains, where each domain contains a 
configuration for a system running on a physical network. There can thus be several domains operating 
5 concurrently on any physical network, and these domains can be managed by the user in accordance with 
the invention by configuring the nodes into non-overlapping domains. Also, the invention may automatically 
determine the optimal allocation for data manipulation in order to balance the system load. Accordingly, 
these and all such modifications are intended to be included within the scope of this invention as defined in 
the following claims. 
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APPENPIX A 



The following routines are used for initializing or 
removing -conununication to the system of the invention: 



- Splnit: Used to initiate conununication between the 
system and the calling process « 

Sp£bd: Used to end coxomunication and cleamup 
resources allocated by the system for the calling 
process • 

The following function is used to transfer messages 
between processes: 

- SpSendMsg: Used to send a message to a process « 

The following function is used for trsmsf erring files: 

- SpSendFile: Used to copy or append a file to a 
destination file. 

The following functions are used to control system 
processes: 

*- SpStartProcess: Used to start a system process. 
" SpStopProcess : Used to stop a system process. 

The following function is used to read incoming 
messages : 

SpReadQ: Used to read messages from the process' 
incoming message queue. 

The following function is used to control user access 
routine options: 

-SpControl: Used to set user**controlled options for 
the system access routines. 

The following function is used to allow the user to 
access the system error logger: 

- SpErrliOg: Used to allow the user to send application* 
specific messages to the system error logger. 

The following function is used to clear the application 
queue. This function should be used with care. 

• SpFlush: Used to set user-controlled options for the 
system access routines. 
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Access Routiine Examples 

Splnit - Every process must do an Splnit. In this 
example, SpInlt initiates communication between the 
integration system and the process named mrp01cp« 



int rc; 

int i; 

int 1njist[5], outJist[5]; 

Int flags; 

char srcprocln[16]; 



for(i -0; i<5; i++) 

^ 1nJ1st[1]-0; 
outjist[i]-0; 

fl ags - 0; 

strcpy (srcprocln, ■nrpOlcp"); 

if ((rc»SpIn1t(nags. srcprocln, injist, outjist)) !-0) 

^ printf ("ERROR: Splnit of %s returns %d\n", srcprocln, rc); 
exit{l); 

el se printf ("Splnit was successful . . A"" f rc) ; 
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SpEnd - SpEnd ends comnixinication between the 
integration system and a process. 



int rc; 
int flags; 



flags«0; 

if ((rc-SpEnd(nags))J-0) 

printf ("ERROR: SpEnd returns «d\n", rc) ; 

else 

printf ("SpEnd was successful . . An" , rc) ; 



SpSendMsg In this example, SpSendMsg sends a message to the message buffer called 
SCHWOFILE in the process named schOlcp. 



int rc; 

iSt in list[5], outJist[5]; 

int flags; 

char desprocln[16]; 

unsigned char dfilename[MAXBUFSIZ£] ; 

char linkname[16]; 



for (i -0; i <5; i++) 

^ in listCl]-0; 
outJistCl] -0; 

) 

f 1 ags - 0 ; 

strcpy (desprocln, "schOlcp"); 

strcpy (df i 1 ename , SCHWOFILE) ; 

strcpy (linkname, ""); 

in 11st[SpBUF LEN] - strlen(dfilenaine) +1; 

inIlist[SpTAGT-l; 

if ((rc-SpSendMsg(flags, desprocln.df 11 ename, linkname, in_11st, 
outjist)) !-0) 
printf ("ERROR: SpSendMsg returns %d\n" , rc) ; 

else 

printf { "SpSendMsg successful . . .\n" ) ; 
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• 



SpSendFUe • In this example, SpScndTile sends liie source Ck MRPWOFILE to the 
LOCINFO Glc la the process named schOlcp. It oses the Qle attributes 



injist[13 -0; 
out list[l]-0; 

} 

flags - 0; 

strcpy (desprocln, "schOlcp"); 
strcpy (srcfile, MRPWOFILE) ; 
strcpy (dfilename. SCHWOFILE); 
strcpy (desfile, LOGINFO); 
strcat (desfile, dfilenarae); 
strcpy (linkname, "linkfl"); 

If ((rc"SpSendFne(flags. desprocln, srcfile, desfile, linkname, injist. 
outjist)) !-0) 
printf ("ERROR: SpSendFile returns %d\n", rc) ; 

else 

printf ("SpSendFile successful . . .\n") *» 



spedCed in the link Gle linkfl. 



int 
int 
int 
int 
char 



rc; 
1; 

injist[5], outJistCS]; 
flags; 

desproclnCie] ; 
srcfileCHAXBUFSIZE]; 
dfilenaine[MAXBUFSI2E3; 
desfile[MAXBUFSIZE]; 
1 inknaine[16] ; 



unsigned char 
unsigned char 
unsigned char 
char 



for (i -0; i <5; i++) 
{ 
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SpStartProcess 



la this atamplc SpSianProccw starts the process named scbOlcp, 



int rc; 

int injist[5], outJistCB]; 

Int flags; 

char desprocln[16]; 

char runstr1ng[128]; 

char execinfo[2563; 



for (i -0; i <5; i++) 

^ in T1st[l]-0; 

out list[l]-0; . 

) 

fl ags - 0 ; 

strcpy (desprocln, "schOlcp"); 
strcpy (runstring, "■); 
strcpy (execinfo, "); 
inj istCSpPASSWD_NUMl - 100; 

if ({rc - SpStartProcess(flags. desprocln, runstring, execinfo. Injist, 
outjist)) l-O) . i 

printf ("ERROR: SpStartProcess returns %d\n , rc) ; 

else , , V .» 

printf ("SpStartProcess successful .. A" )*. 
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SpStopProcess In this example, SpStopProccss stops a process named testOZ" when the 
rap;«g program receives the SIGUSRl intemipL The password number 
in list parameter must match the password number spedGed for this 
process in the Process Definition configuration file to stop this process. 



int flags; 

char desprocln[16] 

int in list[5],out I1st[5]; 



• 

flags -0; 

strcpy(desprocln, "testOZ"); 
in list[SpPASSWD NUM3 -100; 
In'l istCSpST0P_ST6] - SIGUSRl ; 

if ({rc-SpStopProcess(flags. desprocln, injist, outjist)) I-O) 

printf( "ERROR: SpStopProcess returns Sd\n", rc); 
exit{l); 

else 

printf ( 'SpStopProcess was successful .\n") ; 
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SpReadQ In this csample, SpRcadQ reads the incoming message area and plac 
the message with the tag value of 1 in the buffer area. 



Int rc; 

int i; 

int 1njist[5], outJist[5]; 

int flags; 

char prQcln[16]; 

unsigned char buffer[MAXBUFSIZE] ; 



for (i -0; 1<5; i++) 

^ In list[l]-0; 
outJist[l] -0; 

fla s 0- 

in^?is"t[SpBUF LEN] - MAXBUFSIZE; 
in"list[SpTIMEOUT]«0; 
in"list[SpLOWER.TAGI-l; 
1nJist[SpUPPER_TAG]-0; 

i f ( ( rc - SpReadQ ( f 1 ags , procl n , buffer , 1 n 1 1 s t , out J i s t ) ) ! -0 ) 

printf ("ERROR: SpReadQ returns %d\n^, rc); 

else 

printf ("SpReadQ successful , • An") ; 
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spControl 

In this example, th& SpControl function parzuneter 
SpSET_ FILE_ NOTIF notifies the calling program when a file sent 
through the system is available to it. The calling program is 
notified by means of the interrupt SIGUSRl specified in the 
in_^list parameter. 



int func; 

Int in llstCS], outJ1st[5]; 

int 1;" 

void handler_routlne{ ); 

static struct sigvec sig_hdlr - {handler_routine, 0, 0); 

/* Set up a handler for SIGUSRl signal. */ 
sigvector (SIGUSRl, isig_hdlr, 0); 



func - SpSrr_FILE_NOTIF; 
for (i - 0; i < 5; i++) 
{ 

injist[i] - 0; 
out list[i] - 0; 

) 

injist[0] - 1; 
injist[l] - SIGUSRl; 

if ((rc - SpControl (func, HULL, in list, outjist)) I-O) 
{ 

printf(" ERROR: SpControl of %s returns Sd\n", procln, rc); 
exit(l); 

} 

else 
{ 

printf ("SpControl was successful... \n", rc); 

) 



void handler routine( ) 
{ 

printf ("In handler routine ...\n"); 

) 
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SpErrliOg 

This example shows using SpErrLog to include a user- 
written error message in the system's error logger. 



char ernnsg[MAXMSGSI2E]; 
int ernnsglen; 



strcpy(ernnsg, "User Error Msg: From recvstop process at stepK"); 
errmsglen- strl€n(ernnsg); 

if ({rc-SpErrLog{ernnsg, ernnsglen)) !-0) 

printf(" ERROR: SpErrLog returns r«d\n", rc) ; 

else 

printf ("SpErrLog was successful . . An ) ; 



In this example, SpError retrieves an ASCII message 



buffer corresponding to a system error number. 



Int rcl; 
int rc; 

char ernnsg[MAXMSGSIZE]; 



if ((rcl -SpError (rc, errmsg)) 1-0) 

printfC ERROR: SpError returns %d\n", rcl); 

else 

printf("Errorinsg isXs". errmsg); 
exit(l); 
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SpFIasb SpFlush fltuiies pending reques£ and clears Uxc timeom iist for the 

process. Use it only if your adaptor uses an interrupc-handlizig rouune 
that needs to do a longjmp when it is called. 



jmpbuf signal jnipbuf; 
setjnip{ si gnal_ jmpbuf) ; 



/♦This section of the program describes an infinitewait using */ 
/* theSpReadQ access routine to read incoming messages. V 



/♦The interrupt handler V 
void interrupt_handler{ ) 

extern jmp^buf si gnal_jmpbuf; 



printf("In signal handler function. \n"); 
Int rc; 

if ((rc-SpFlushO) !-0) 

printf( "ERROR: SpFlush returns Sd\n" 



SpDelGumrmnteedMsg This is an example of using SpOelCuarameedMsg to delete a guaranteed 

message. 



if ((rc - SpDe1GuaranteedNsg( )) 1-0} 

{ 

printf ("ERROR: SpOelGuaranteedMsg returns %d\n", rc); 

else 

printf ("SpOelGuaranteedMsg successful . . An" ) ; 
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Exaunple Adaptor Programs 

This is a brief description of the functions of the 
adaptors created for the integrated system exauople, 

mrpoicp The mrpOlcp adaptor initiates the system process 

mrpOlcp which sends a work order file and a message 
containing the destination file name to the schOlcp 
process. The mrpOlcp process also starts up the 
schOlcp program. MrpOlcp uses these calls: Splnit, 
SpStartProcess, SpSendFile, SpSendMsg, and SpEnd. 

schOlcp The schOlcp initates the system process schOlcp that 
uses a SpReadQ call to get the name of the work order 
file sent from mrpOlcp. SchOlcp opens the work order 
file and generates a new dispatch file called SCHDISPF. 
SchOlcp uses these calls Splnit, SpReadQ, and SpEnd.. 
It sets the flat SpDELETE_ALL with the Splnit to delete 
all messages that have been stored for this process. 

sch02cp The sch02cp adaptor initiates the system process 

sch02cp. Sch02cp sends messages to process ctlOlfp and 
receives messages from ctlOlfp, Sch02cp uses these 
calls: Splnit, SpSendMsg, and SpEnd. 

ctlOlfp The ctlOlfp adaptor in FORTRAN initiates the system 

process ctlOlfp that hangs on an SpReadQ call waiting* 
for a data message from the process sch02cp. CtlOlfp 
processes the data in the message and returns to wait 
for another SpReadQ call. The ctlOlfp process also 
sends messages to two other processes: sch02cp and 
mrp02cp. 

ctlOlpp The ctlOl pp adaptor is a passed version of ctlOl fp. 

mrp02cp The mrp02cp adaptor initiates the background process 
mrp02cp that hands on an SpReadQ call waiting for a 
data message from the process ctlOlfp. Mrp02cp uses 
these calls: 

Splnit, SpReadQ, and SpEnd. 

These are additional programs created for this work order 
management example: 

exOl.h This is a header file that defines the file directories 
and structures for the adaptors used in this system 
example • 

datagen This is a program to solicit user input for creating a 
work order database. 
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Adaptor 
Examples 
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mrpOlcp 



10 



75 



/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 




JSource: mrpOlcp.c 
SRevision: 1.1 $ 

This is a skeleton application adaptor to send a file 
to another HP Sockets adaptor. The mrpOlcp adaptor initiates the mrpOlcp / 
process which sends a work order file and a message containing the */ 
destination file name, to the schOlcp process. The mrpOlcp process also */ 
executes the schOlcp program. MrpOlcp uses these calls: Splnit, / 
SpStartProcess, SpSendFile. SpSendHsg, and^SpEnd.^^^^^^^^^^^^^^ 



20 



/ 



This is the maximum message size HP Sockets allows. 
Change it to the size that the application needs. 



V 



25 



Idefine MAXBUFSIZE 1024 
#define HAXMSGSIZE 500 

/♦ Global include files */ 
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#include <stdio.h> 
linclude <Sp.c.h> 
finclude "exOl-h" 



/* HP Sockets header include file for C programs */ 
/* Data and file definitions for work order roanageraent 
examples */ 



35 



Main program 



V 



40 



main( } 

These are suggested parameter definitions for all access routine calls. 



int 

45 int 

unsigned char 
char 



rc; 

buflen; 

buffertMAXBUFSIZE]; 
proclnC16]; 



/* Access routine return code 
/* Data buffer length 
/* Data buffer received 
/* Process name initiate 



V 
V 
V 
V 
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char 
char 
char 

char 
char 



1nt 

int 

char 

1nt 

Int 



srcprocln[16]; 
desproc1n[16] ; 
1inlcnarae[16]; 

runstring[128]; 
execinfo[256] ; 



fl ags; 
func; 

errmsgEHAXHSGSIZE]; 
errmsgleh; 
inJ1st[5], 
outJ1st[5]; 



/* Source process name 
/* Destination process name 
/* Destination process name 

/* Runstring for SpStartProcess 
/* Execution information for 
SpStartProcess 

/* Flag parameter 

/* Set function for SpControl 

/* Return error buffer 

/* Set error message length 

/* Additional input parameters 

/* Additional output parameters 



V 
V 
V 

V 

V 

V 
V 
V 
V 
V 
V 



These are special parameters used in this program. 



V 



int i; 

unsigned char srcfile[MAXBUFSIZE] ; 

unsigned char desfile[MAXBUFSIZE] ; 

unsigned char dfilename[MAXBUFSIZE]; 



/* Source file name 

/♦ Destination file name 

/* Destination file name only 



V 
V 
*/ 



start communications with HP Sockets- Set up the parameters and 
make the Splnit call. 

for {i • 0; i < 5; i++) 
{ 

fnjist[i] - 0; 
out listti] - 0; 

) 

flags - 0; 

strcpy (srcprocln. "mrpOlcp"); 

If ((rc • Splnit{flags, srcprocln, in list, outjist)) !- 0) 
{ 

printf( "ERROR: Splnit of %s returns Sd\n", srcprocln, rc); 
exit(l); 

} 

else 

printf("SpInit was successful . .An*» rc); 
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After each call, reset the parameters. Hake the SpStartProcess 
call to execute schOlcp, 



for {i - Ch; i < 5; 

{ 

10 InJIstti] - 0; 
out list[1] - 0; 

} 

flags - 0; 

strcpy{desprocln, "schOlcp"); 

strcpy(runstring, ""); /* Use default runstring 1n proc.def */ 

strcpy{execinfo, ■"); /* Use default execution info In proc-def V 

in_list[SpPASSWD_NUM] - 100; /* Password number 100 was defined in Proc.def*/ 

if ((rc - SpStartProcess(flags, desprocln, runstring, execmfo, 

injist, outjist)) !- 0) 
printf ("ERROR: SpStartProcess returns %d\n", rc); 

else 

25 printf ("SpStartProcess successful An") ; 



Send file with wait. We use the 60 second default timeout. 
If you need a longer timeout value, use SpControl to 
set up the timeout value. 



for (i - 0; i < 5; i++) 

35 { 

injist[i] - 0; 
out_list[i] - 0; 

} 

flags • 0; 

strcpy(desprocln, "schOlcp"); 

strcpy(srcfile, MRPWOFILE); 
45 strcpy{dfilename, SCHWOFILE); 
strcpy(desfile, LOGINFO); 
strcat(desfile, dfilename); 
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strcpy(l inkname, "linkfl"); 

If {(rc • SpSendFne(fIags, desprocln, srcfile, desfile, 1 inkname, 

InJIst, outjist)) !- 0) 
printfC ERROR: SpSendFile returns Sd\n", rc); 

else 

printf ("SpSendFile successful , . .\n"); 



After the file has been sent» bundle a message that 
contains the destination file name. Send this message 
to the destination process • 



for (i • 0; i < 5; i++) 
( 

injist[i] - 0; 
out list[i] - 0; 

} 

flags - 0; 

strcpy(desprocln, "schOlcp"); 

strcpy(srcfile, MRPWOFILE); 
strcpy(dfilename, SCHWOFILE); 

strcpy(l inkname, ""); 

In list[SpBUF LEM] - strlen(dfilenam€) + 1; 
inJist[SpTAG] - 1; 

if ({rc ■ SpSendMsg( flags, desprocln, dfilename, linkname» in_li$t. 



outjist)) !-0) 



{ 



printf ("ERROR: SpSendHsg returns %d\n", rc); 



) 

else 



printf ("SpSendHsg successful . . A"') ; 



/* End communications with HP Sockets 



V 



flags - 0; 



if {(rc - SpEnd(flags)) !-0) 

printf ("ERROR: SpEnd returns W\n", rc); 



else 



printf("SpEnd was successful An", rc); 



} 
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schOlcp 



/* SSource: schOlcp.c V 

/* SRevision: 1.1 $ V 

/* V 

/* This program initiates the schOlcp process that uses a SpReadQ call */ 

/* to get the file name of the work order file sent from the mrpOlcp process- V 

/* It opens this work order file and generates a new dispatch file V 

/♦ called SCHDISPF, SchOlcp uses these calls: Splnit, SpReadQ, V 

/* and SpEnd. It sets the flag SpDELETE^ALL with Splnit to */ 

/* delete all messages that have been stored for this process. */ 
/* 



This is the maximum buffer size allowed by HP Sockets. 
Change it to the size that the application needs. 



#define MAXBUFSI2E 1024 
Idefine HAXMSGSIZE 500 

/* Global include files */ 



llnclude <stdio.h> 
finclude <signal.h> 
♦include <time.h> 

finclude <Sp,c.h> /* HP Sockets header include file for C programs ♦/ 

llnclude "exOI.h" /* Data and file definitions for work order management 



examples V 

/* Function: process^file */ 

/* Parameter: filename */ 

/* Return: normal - 0, error • -1 V 

/* V 

/* Description: This function reads a work order file */ 

/* and generates a dispatch file. */ 

/* V 

/* argument mean i ng V 
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Int proc8ss_fne{f llename) 
char *filenaine; 

{ 

FILE *wo fp, /* file descriptor */ 

*disp_fp; /* file descriptor */ 

wo_rec *wo_ptr, wo_buf; 

d1sp_rec *dispjtr, disp_buf; 

int i; 



long cur^time; /* The current t1me(seconds since Jan 1, 1970)*/ 

char *char_str_ptr; 
char time_str[5]; 
25 char date_str[73; 

/* Get the system's time. — */ 

cur_time - time{(long *) 0); /* Get the system's time- */ 
char_strjtr - nl_cxtlme(icur_tinie, ■%ySmSd*); 
stmcpy(date_str, char_str_ptr, 7); 

disp_ptr • ldisp_buf; 
wo_ptr - &wo_buf ; 

/* — — Open the work order file for a read «« V. 

if( (wo_fp - fopen (filename, "r")) — NULL) 
{ 

printf ("Could not open work order file XsAn", filename); 
retum(-l) ; 

) 

/* «•«•- Open the dispatch file for a write — — • */ 

else if ( (disp.fp - fopen(SCHDISPF, "w")) NULL) 
( 

printf ("Could not open dispatcher file %s.\n", SCHDISPF); 

50 
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return (-1) ; 



/ 



Simulate a schedule system application that generates dispatch information. 



70 



75 



20 



25 



while {{1 - fread{wo_ptr, sizeof(wo rec). It wo^fp)) — 1) 
( 

printfCIn fread loopAn"); 
strcpy(d1sp_buf .wo_no, woj)tr->wo_no) ; 
d1sp_buf.qty « wDj)tr->qty; 
strcpy(disp_buf-part_no, woj>tr->part_no); 
strcpy(d1sp3buf .start_date, date^str) ; 
strcpyCdisp'buf.start^time, "0800"); 
strcpy(disp_buf,stop_date, date^str); 
strcpy (di sp_buf . stop_t ime , "0900" ) ; 

if((i • fwrTte(d1spjtr, $izeof{disp rec), 1, disp_fp) ) !- 1) 
{ 

printf{"fwr1te error for %sAn', SCHDISPF); 
return(-l); 



} 



) 



30 



fclose(wo_fp) ; 
fclose(disp_fp) ; 



} 



Main program 



/* Close work order file */ 
/* Close dispatch file */ 



36 



main(} 
C 



40 



These are suggested parameter definitions for all access routine calls. 



45 



int 
int 

unsigned char 

char 

char 

char 



rc; 

buflen; 

bufferCHAXBUFSIZE]; 
procln[16] ; 
srcproclntlB]; 
desprocln[16] ; 



/♦ Access routine return code 

/* Data buffer length 

/♦ Data buffer received 

/♦ Process name initiate 

/* Source process name 

/* Destination process name 



V 
V 
V 
V 
V 
V 
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char 

char 
char 



Int 

Int 

char 

Int 

int 



1 1nkname[16] ; 

run$tring[128] ; 
execinfo[256]; 



flags; 
func; 

errrosg[HAXHSGSIZE]; 
errmsglen; 
injist[5]. 
outJ1st[5]; 



/* Destination process name 



V 



/* Runstring for SpStartProcess */ 
/* Execution Information for 

SpStartProcess */ 

/* Flag parameter */ 
/* Set function for SpControl */ 
/♦ Return error buffer */ 
/* Set error message length */ 
/* Additional input parameters */ 
/* Additional output parameters */ 



These are special parameters used in this program. 



int 
int 



i; 

still have work « 1; 



/* True for do loop 



Start conrauni cat ions with HP Sockets- Set up the parameters and 
»ake the Splnit call. 



for (1 - 0; i < 5; i++) 
C 

1njist[1] - 0; 
outJist[1] - 0; 

} 

flags - SpDELHE^ALL; 
strcpy(srcprocln, "schOlcp"); 

if ({rc « Spln1t(flags, srcprocln. In list, out_list)) !• 0) 
{ 

printf ("ERROR: Splnit of Ss returns Sd\n", srcprocln , rc); 
exlt(l); 

} 

else 

printf ("Splnit was successful An" i rc); 



Do an SpReadQ call to get the name of the work order file 
in the message sent by the mrpOlcp program. 



V 



V 
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.....„„„..-.„— — - V 

for (i - 0; 1 < 5; i-H-) 
{ 

InJIstfi] - 0; 
out Usttj] - 0; 

) 

flags - 0; 

In list[Sp8UF LEN] - MAXBUFSIZE: 

1n~11st[SpTIME0UT] - 0; /* Set timeout forlnfinite wait. */ 

/* Default is 60 seconds. */ 

In list[SpLOWER TAG] - 1; 
1nJ1st[SpUPPER_TAG] - 0; 

If {(rc - SpReadQ (flags, procln, buffer, injist, out J 1st)) 
!- 0) 

printf ("ERROR: SpReadQ returns %d\n", rc); 
else 
{ 

printf ("File %s rece1ved.\n", buffer); 

process fne(buffer); /* Call the function defined above 

) " . 

/* ..... End communications with HP Sockets •-— V 

flags - 0; 

for (1 - 0; 1 < 5; i++) 
( 

In list[i] - 0; 
out list[i] - 0; 

) 

if ((rc - SpEnd( flags)) !- 0) 

printf ("ERROR: SpEnd returns %d\n", rc); 
else 

printf ("SpEnd was successful .. .\n") ; 



41 



EP 0 456 249 A2 



sch02cp 



^i ikMk t ★★^r#»^*»-»-<f*--»*1r'»»*»ir** ir fc* » * ★★★^t*ic-fc-Jr* kk -kk k k -kit** j 



/* 
/* 
/• 
/* 
/* 
/* 
/* 
/* 
/ 



Source: 
SRevislon: 



sch02cp.c 
1.1 $ 



This is an application adaptor to send messages to 
another HP Sockets adaptor. The sch02cp adaptor initiates 
the schOZcp process which sends messages to process ctlOlfp 
and receives messages from it. SchOZcp uses these calls: 
Splnit, SpSendHsg, and SpEnd. 



V 
V 
•/ 
V 
V 
V 
V 
V 



This is the maximum buffer size HP Sockets allows. 
Change it to the size that the application needs. 



idefine MAXBUFSIZE 1024 
#define MAXMSGSIZE 500 

'/* Global Include files */ 

linclude <stdio*h> 



V 



#include <Sp.c,h> 
#include "exOKh" 



/* HP Sockets header include file for C programs */ 
/* Data and file definitions for work order management 
• examples */ 



Main program 



V 



main(} 
{ 

/* .... 



These are suggested parameter definitions for all access routine calls. 



V 



int rc; 

int buflen; 

unsigned char buffer [MAXBUFS IZE] ; 

char procln[16]; 



/* Access routine return code */ 

/♦ Data buffer length */ 

/* Data buffer received */ 

/♦ Process name initiate */ 
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Char 
char 
char 

char 
char 



int 

Int 

char 

int 

int 



srcprocln[16]; 
desprocln[16]; 
linkname[16]; 

runstring[128]; 
execinfo[2S6]; 



flags; 
func; 

ernnsg[HAXHSGSIZE]; 
ernnsglen; 
1nJist[S], 
outJist[5]; 



/* Source process name ♦/ 

/* Destination process name V 

/* Destination process name */ 

/* Runstring for SpStart Process ♦/ 
/* Execution information for 

SpStartProcess V 

/* Flag parameter V 

/* Set function for SpControl ♦/ 

/♦ Return error buffer ♦/ 

/* Set error message length V 

/* Additional input parameters */ 

/* Additional output parameters V 



/* ——These are special parameters used in this program. — — — */ 



int 
char 



i; 

contchar, 
dummy [80] ; 



disp_rec *dispj)tr, disp^buf; 

wo_compl_s_rec *comp_ptr, comp^buf; 



FILE 



*disp_fp; 



dispjjtr « idisp^buf; 
comp^ptr - icomp_buf ; 

/* open the dispatch file for a read 



if ( (disp_fp - fopen(SCHDISPF, "r")) — NULL) 

^ printf ("Could not open dispatcher file SsAn", SCHDISPF); 
exit(l); 

} 



/ 



Start communications with HP Sockets. Set up the parameters and 
make the Splnit call. 



for (i - 0; i < 5; i++). 
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{ 

InJIstCi] - 0; 
out 11st[i] - 0; 

} 

flags - 0; 

strcpy(srCprocln, "schOZcp*); 

if ((re - Splnit(flags, srcprocln, Injist, outjist)) I- 0) 

pr1ntf( "ERROR: Splnit of %s returns Sd\n", srcprocln , rc); 
ex1t(l): 

} 

else 

pr1ntf{" Splnit was successful .. .\n"t rc); 



This is the area where the data from the application should 
be accessed (the file is read, the shared meuwry area is 
accessed, etc). This portion is application-specific. 

This data should be placed in the buffer variable "buffer", 
and the number of bytes should be put into variable "buflen". 
— — — — — V 

/* ..... Initialize the continuous flag to yes -—- */ 

contchar - 'y'; 

/* -— . Read the dispatch record — — */ 

while { ({i - fread{dispj>tr, sizeof(disp_rec), 1, disp_fp)) — 1) 
XS, (ecntchar — 'y') } 

{ 

printf("Do you want to send this dispatch record to control $ystem?\n"); 

contchar - getchar(}; 

gets (dunsny } ; 

If {contchar — 'y') 

{ 

/* — — """" 

Use SpSendHsg to send the dispatcher buffer to a FORTRAN 
controller program. 

— „„— — „—„..„-.. — — V 
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for(i - 0; i < 5; i++) 
{ 

In 11st[i] - 0; 
outJIstCi] - 0; 

) " 

flags - SpNOWAn_FLAG; 
strcpy(desprocln, "ctlOlfp"}; 
strcpy(11nkname, "linkl"); 
in HsttSpBUF_LEN] - si2eof (disp_rec) ; 
1nJist[SpTAG] - 10; 

if {(rc - SpSendHsg( flags, desprocln, dlsp_ptr, linkname, 
In list, out list)) !- 0) 

{ 

printf(" ERROR: SpSendHsg of returns y.d\n". rc); 

} 

else 
{ 

printf ("SpSendHsg successful .. .\n") ; 



Do a ReadQ with a long wait to get the work order complete 
message from the cell controller application. 

« — .« — — V 

for (i - 0; i < 5; i++) 
{ 

inJistCi] - 0; 
out list[i] - 0; 

} 

flags - 0; 

in list[SpLOWER_TAG] - 0; 
in~list[SpBUF.LEN] - si2eof(comp_buf); 

inJist[SpTIMEOUT] - 0; /* Infinite wait. Default is 60 sec */ 

if ((rc - SpReadQ(flags, procln, icomp buf, injist, out J 1st)) >0) 

( 

printf{" ERROR: SpReadQ of returns %d\n", rc); 

) 

else 
{ 
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printf CSpReadQ successful . . An") ; 

printf("The previous work order had been completed An"); 
printf {"wo_comp_wo_no - %s\n", comp^buf .wo_no) ; 
prlntfCwo^comp^part^no - %s\n", comp^buf .part^no) ; 
printf("wo comp qty « %d\n", comp^buf .qty) ; 

) 

} 

) 

} 

/* — — End coimuni cations with HP Sockets — */ 

If ({rc - SpEnd(nags)) 1- 0) 

printf ("ERROR: SpEnd returns ?id\n". rc); 
else 

printf (" SpEnd was successful An", rc); 

} 
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CtlOlfp 

FORTRAN programs on the HP9000/S800 require the 
LITERAL^ ALIAS ON dircaivc shown in this example. This directive 
specifies Uiat any cwemaJ names in an ALIAS directive are processed as 
they appear, that is, they arc neither upshilted nor downshifted. The 
default is OFF and cxtemai names are upsliiftcd or downshifted according 
to the UPPERCASE dircaiVB setting. Refer to \hc HP FORTRAN 17 
Reference Manual (Pan member 5957-4685). 



JLITERAL^ALIAS ON 

C C 

C Source: ctlOlfp.f C 

C SRevision: 1.1 $ C 

C C 

C This is a FORTRAN application adaptor that initiates the C 

C process ctlOlfp which hangs on an SpReadQ call waiting for C 

C a data message from the process sch02cp. CtlOlfp processes C 

C the data in the message and returns to wait for another C 

C SpReadQ call. The ctlOlfp process also sends messages to C 

C ,two other processes: schOZcp and mrp02cp. C 

program ctlOlfp 



JINCLUDE 'Sp.f.h' 



integer 


rc 


integer 


buflen 


character 


buffer(1024) 


character*16 


procln 


character*16 


srcprocln 


character*15 


desprocln 


character*16 


1 inkname 


character*128 


runstring 


character*256 


execinfo 


Integer 


flags 


integer 


func 


character*2S5 


errmsg 


integer 


errmsglen 


integer 


timeout 
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integer nist{5), olist(S) 

C ****** Declaration section ****** 

integer i 

character*1024 msgbuf 

C Field definitions (dispatch information) for main example 

character*16 part_no 

character*10 wo_no 

Integer qty 

character*6 start_date, stop^date 

character*4 start_time, stop_time 

equivalence (msgbuf , buffer) 

equivalence (buffer(l), part^no). (buffer(17), wo.no), 
+ (buffer{29), qty)7 (buffer(33), start.date), 

+ (buffer{39)» start.tioe). (buffer(43)7 stop.date), 

+ (buffer{49), stop_time) 

character outbuf(38) 

C Work complete information 

character*18 c_part_no 
character*12 cjfojno 
integer c_qty 
character*8 c_date_conip 

equivalence (outbuf(l), c_part_no), (outbuf(19), c_wo_no), 
+ (outbuf(33), c^qty)7 (outbuf(37), c_date_comp) 

C Start communications with HP Sockets 

do 10 i-l,5»l 
ilist(i)-0 
olist(i)-0 
10 continue 

flags • 0 
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srcprocln - "ctlOlfp" 
NULL terminate the process logical name like a C string 
srcpYocln{6:6) - char(O) 
rc - spinit(flags, srcprocln, ilist, olist) 

if ( rc .NE. 0) then 

write (*,*) "ERROR: spinit return - rc 

goto 999 
else 

write(*,*) "spinit successful" 
endif 

Use an SpReadQ in a loop to read messages from the 
schOlcp program 

100 continue 

flags - 0 

nist(SpL0WER_TA6)-0 
il1st(SpUPPER TAG)-0 
llist(SpBUF_LEN)-1024 
ilist (SpTIMEOUT)-O 
ilist{5)-0 

oHst(l)-0 
olist(2)-0 
olist(3)-0 
ol1st(4)-0 
ol1st(5)-0 

rc - spreadq (flags, procln, buffer, ilist, olist) 

if ( rc .NE. 0) then 

write{*,*) "ERROR: spreadq fail ", rc 

goto 999 
else 

write(*,*) "spreadq successful" 
end if 



49 



EP 0 456 249 A2 



If we get a message with tag-9999, end the loop 

If (ollst(SpTAG) .EQ, 9999) then 

go to 200 
endif 

Display the message received 
write{*,*) 

write(*,*) "Get dispatch buffer 
write(*,*) "part-no - part_no 
wr1te(*,*) "wo-no - wo_no 
write(*,*) -qty - qty 
write(*,*) "start^date - start^date 
wr1te(*,*) "startltlme - start^tlme 
write(*,*) •'stop_date - stop^date 
write(*,*) "stop^time • stop_time 

Simulate the work complete message 

wrne(*.*) 

write(*,*) ■***The work order has been completed *** 
write(*,*) "***Send work order completion info to *** 
write(*,*) "***HRP and SCHED applications *** 
write(*,*) 

Use SpSendHsg to send the work order complete message to 
the mrp02cp process using link3 for data conversion. 

c_part_no - part_no 
c_wo_no • wo_no 
c.qty - qty 
c_date_comp - "891127* 

flags « 0 

desprocln - ''mrp02cp" 
desprocln(6:6) - char(O) 

linkname • "link3" 
linkname(6:6) - char(O) 
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ilist(SpCLONEJD)-0 
ilist(SpTAG)-100 
5 nist(SpBUF_LEN)-38 
nist(4)-0 
ilist(5)-0 

o1ist(l)-0 
'° olist(2)-0 
ol1st(3)-0 
olist(4)-0 
o11st(5)-0 

75 

rc - spsendrasg(flags, desprocln, outbuf, linknarae, ilist, oHst) 

if ( rc .NE. 0) then 

wr1te(*,*) "ERROR: spsendmsg fail rc 

goto 999 
else 

write(*,*) "spsendmsg successful" 
end if 

25 

C Use SpSendHsg to send the work order complete message to 
C the sch02cp process using link2 for data conversion. 

30 flags - 0 

desprocln - "schOZcp", 
desprocln(6:6) - char(O) 

35 

linkname - "link2" 
linkname(6:6) « char(O) 

ilist{SpCLONE ID)-0 

iHst(SpTAG)-T00 

ilist(SpBUF_LEN)-38 

ilist(4)-0 

ilist(5)-0 

45 

olist{l)-0 
olist(2)-0 
olist(3)-0. 
50 olist(4)-0 
olist(5)-0 
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rc • spsendmsg( flags, desprocln, outbuf, llnkname. Hist, olist) 

If ( rc .NE- 0) then 

wr1te(*,*) "ERROR: spsendmsg fail rc 

geto 999 
else 

write(*,*) "spsendmsg successful" 



end If 

go to 100 

C End communication with HP Sockets 

200 continue 

20 rc - spend(flags) 

if ( rc .NE. 0) then 

write(*,*) "ERROR: spend fail ", rc 

goto 999 
25 else 



wr1te(*,*) "spend successful" 
end if 
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999 stop 
end 
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5LIST ONS 

{This Pascal version of the ctlOlfp process is constructed similarly 
to the FORTRAN version in order to make it easy to see the correspondence 
between the individual items and "procedures' in the two versions. If 
you use this Pascal adaptor template, you may wish to restructure 
this program to conform to good Pascal programming construction. } 
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PROGRAM ctlOlpp (Input, Output); 

{This Pascal application adaptor (process ctlOlpp) is run as a 
background (daemon) process. It hangs on the SpReadQ access routine 
waiting for the message sent by the scheduling process (sch02cp) that 
the work order is ready to be processed. Process ctlOlpp then sends the 
message that the work order has been completed to schOZcp and rorp02cp.} 



LABEL 999; 

$ INCLUDE '/usr/include/Sp.p.h'J 



TYPE 



Strlngie • str1ng[161; . 
StringlO - string[10]; 
Strings - string [6]; 
String4 - string[4]; 

WorkOrderIn » RECORD 

part^no: StringlS; 
wo_no: StringlO; 
qty: Integer; 
start jdate: Strings ; 
start_t1me: String4; 
stop_date: Strings ; 
stop^time: String4; 

END; 



(Header file containing) 
{type definitions for Pascal) 



(The work order information ) 
(coming from schOZcp) 



DispRecord • RECORD 

CASE b: Boolean OF 

TRUE : (dispchar : SpMsgBufType); 
FALSE: (di spree : WorkOrderIn); 
END; 



(Transfer character buffer to record) 
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WorkOrderOut ■ RECORD {The work order Information ) 

c_part_no: str1ng[ia]; {going to ntrpOZcp and sch02cp} 
c_wo_no: string [12]; 
c_qty: Integer; 
_ c_date_comp: string[8]; 
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VAR 
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25 



OutRecord - RECORD 

CASE b: Boolean OF 
TRUE : (dispchar 
FALSE: (di spree 

END; 



{Transfer character buffer to record) 

SpHsgBufType) ; 
WorkOrderOut); 



RC, RN: Integer; 
Flags: Integer; 
LinkName: SpLnType; 
Hist, Olist: SpIntArrayS; 
DesProcln, SrcProcln: SpLnType; 
Charbuf: SpHsgBufType; 
DispBuf: DispRecord; 
OutBuf: OutRecord; 
Procln: SpLnType; 



{Return Codes) 



{Dest. process logical names) 
{Send buffer) 

{Variant record variable) 
{Variant record variable) 
{Receive process logical name) 



30 



Count: Integer; 
SINCLUDE Vusr/include/Sp,p2.h'$ 



{Header file containing) 
{type definitions for Pascal) 
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BEGIN {Main Program) 



40 



{Start communications with HP Sockets by using the Splnit access 
routine to initiate the ctlOlpp process. ) 



For Count 1 To 5 DO 
BEGIN 

46 I11st[Count] :• 0; 

01ist[Count] :- 0; 
END; 



so 
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SrcProcIn :- 'ctlOIpp'; 

SrcProcln[6] :• chr(O); (Zero pad for C compatibility) 

Flags :- SpDELETE_ALL; 

RC 5pInit(Flags, SrcProcln, Hist, Olist); 

IF (RC - 0) THEN 
BEGIN 

write! n; 

writeln('SpInit successful'); 
write! n; 

END 

ELSE 

BEGIN 

write! n; 

wrltelnC ERROR: Spin It returns:', RC:5); 
write! n; 

END; 



(Use the SpReadQ access routine in a WHILE loop to hang on a 
message from the sch02cp process. ) 

WHILE (true) DO 
BEGIN 

For Count :- 1 To 5 00 
BEGIN 

I!1st[Count] 0; 

0!ist[Count] 0; 
END; 

I!1st[SpL0WER_TAG] :- 0; 

Ilist[SpBUF_LEN] :- 1024; {The message buffer size) 

Ilist[SpTIHEOUT] :• 0; {Number of seconds to timeout) 

Flags :- 0; 

RC :• SpReadQ (Flags, Procln, CharBuf, IList, Olist); 

IF RC - 0 THEN 
BEGIN 
write! n; 

write!n( 'SpReadQ successful.'); 
write! n; 
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END 
ELSE 

writeln( 'ERROR Number:', RC:5); 

If (OlisttSpTAG] - 9999) THEN 
goto 999; 

DIspBuf •dispchar :- CharBuf; 



(Move the message buffer Information) 
(into the record variable) 



writeln; 

write! n 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 

writeln 



' Part Number:', 
'Order Number:', 
Quantity:', 
' Start Date:', 
' Start Time:', 
' Stop Date:', 
Stop Time:', 



OispBuf.disprec. 
DispBuf .disprec, 
DispBuf ,disprec, 
OispBuf .dlsprec, 
DispBuf .disprec. 
DispBuf,d1sprec. 
DispBuf .disprec. 



part_no) ; 
wo_no) ; 
qty); 

start^date); 
start^time) ; 
stop^date); 
stop_time) ; 



'***The work order has been completed***'); 

'Send work order completion information'); 
'to processes mrp02cp and sch02cp'); 



(Use the SpSendMsg access routine to send a message to the 
sch02cp and mrp02cp processes*) 



OutBuf.di spree. c_part_no :• DispBuf .disprec-part^no; 
OutBuf.di spree. c_wo_no :• DispBuf.di spree •wo^no; 
OutBuf ,disprec.c_qty :- DIspBuf .disprec.qty; 
OutBuf .disprec.c_date_comp :- OispBuf ,d1 spree. stop_date; 



For Count :« 1 To 5 DO 
BEGIN 

Hi St [Count] :- 0; 

01 i St [Count] :- 0; 
END; 



Oesprocln :• 'mrp02cp'; 
DesProcln[6] :- chr(O); 



(Zero pad for C compatibility) 
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LInkName :- 'link3'; 
LinkName[6] chr(O); 



Flags :• 0; 
nisttSpTAG] :• 100; 
nist[SpBUF_LEN] :- 38; 



{Tag value) 

{Length of message in bytes) 



Charbuf :- OutBuf .dispchar; 

RC :- SpSendMsg(Flags, OesProcln, Charbuf, LinkName, Hist, OUst); 

IF (RC - 0) THEN 
BEGIN 
write! n; 

writeln('SpSendMsg successful'); 
END; 

IF RC <> 0 THEN 
BEGIN 
write! n; 

wr1teln( 'ERROR Number:', RC:5); 
writeln 
END; 

IF RC - 0 THEN 
BEGIN 
writeln; 

writeln ('Message sent to process mrp02cp'); 
writeln 
END; 



Desprocln :• 'sch02'; 

DesProclnCS] :- chr(O); {Zero pad for C compatibility) 

LinkName :- 'Hnk2'; 
LinkName[6] chr(O); 

Flags 0; 

IlistJSpTAG] :- 100; (Tag value) 

nist[SpBUF_LEN] :- 38; (Length of message in bytes) 

Charbuf :•• OutBuf .dispchar; 
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RC :- SpSendMsg(F1ags, DesProcln, Charbuf, LinkName. Hist, Olist); 

IF (RC - 0) THEN 
BEGIN 
wn'teln; 

writeln( 'Message sent to process sch02cp'); 
write! n 



{Use the SpEnd access routine to end communication with HP Sockets. } 

25 999: Flags :- 0; 

RC :- SpEnd(Flags) ; 
IF (RC <> 0) THEN 
BEGIN 

30 write! n; 

write!n{' ERROR: SpEnd returns:', RC:5); 
write! n 
END 

35 ELSE 
BEGIN 
write! n; 

write! n(' SpEnd was successful ...') ; 
^ writeln 
END; 

END. (Main Program) 
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END 

ELSE 

BEGIN 
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writein; 

writelnC ERROR: SpSendMsg returns:'. RC:5); 
writein 
END; 
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END; 
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mrp02cp 
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/* 

SourcS": 
SRevislon: 



/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 



mrp02cp.c 
1.1 % 



This is a skeleton application adaptor that initiates the 
background process mrp02cp that hangs on an SpReadQ call 
waiting for a data message from process ctlOlfp. MrpOZcp 
uses these calls: Splnit, SpReadQ. and SpEnd. 
another SpReadQ call. 



V 
V 
V 
V 
V 
*/ 
V 
V 
*/ 
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This Is the maximum buffer size HP Sockets allows. 
Change it to the size that the application needs. 



#def1ne HAXBUFSI2E 1024 
fdefine HAXHSGSIZE 500 

/* Global include files */ 



finclude <stdio,h> 
#include <Sp*c.h> 
#include "exOl.h" 



/* HP Sockets header include file for C programs */ 
/* Data and file definitions for work order management 



examples 



Main program 



V 



mainO 



/ 



These are suggested parameter definitions for all access routine calls. 



V 



int 
int 



rc; 

buflen; 



/* Access routine return code 
/* Data buffer length 



V 
V 



so 
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unsigned char 

char 

char 

char 

char 

char 
char 



int 

int 

char 

1nt 

int 



buffer[HAXBUFSI2E]; 
procln[15]; 
srcproc1n[16]; 
desprocln[16] ; 
11nicname[16]; 

runstr1ng[1283; 
execinfo[2S6]; 



nags; 
func; 

errmsg[MAXMSGSIZE]; 
errmsglen; 
injist(5]. 
outJist[5]; 



/* Data buffer received 
/* Process name initiate 
/* Source process name 
/* Destination process name 
/* Destination process name 



V 
V 
V 
V 
V 



/* Runstring for SpStartProcess */ 
/* Execution information for 

SpStartProcess */ 



/* Flag parameter 

/* Set function for SpControl 

/* Return error buffer 

/* Set error message length 

/* Additional input parameters 

/* Additional output parameters 



V 
V 
V 
V 
V 
V 



/* — «»i«These are special parameters used in this program, 
int i; 
wo_coraplete_rec wo_complete_buf ; 



V 



25 



30 



05 



40 



45 



Start communications with HP Sockets 



V 



flags • 0; 

strcpy (srcprocln, •mrp02cp"); 

if {{rc Splnit{flags, srcprocln, injist, out list)) !• 0) 
{ 

printfC ERROR: Splnit of %s returns %d\n", srcprocln , rc); 
exit(l); 

} 

else 

printf(" Splnit was successful An', rc); 



Loop forever, waiting for messages. Stop at the special 
message with tag-999g. Set timeout for SpReadQ to 
an infinite wait. Default is 60 seconds. 



V 



for (;;) 

c 
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for {i - 0; i < 5; 

( 

in_list[i] « 0; 
out I1st[i] - 0; 

) 

flags • 0; 

In list[SpLOWER TAG] - 0; 
in"list[SpBUF_L£N] - HAXBUFSIZE; 
1nJist[SpTIME0UT] - 0; 

if {{re - SpReadQ{flags, procln, iwo complete buf, In list, out_list)) >0) 
printf ("ERROR: SpReadQ of returns ?id\n", rc); 

) 

else 
C 

printf {"SpReadQ successful . , * 

When this program receives a message with the TAG 
value « 9999, it breaks out of the FOR loop. 
V 

if (outJist[SpTAG] — 9999) 
break; 

printf( "From Control System, wo « JSs has been completed\n", 

wo_completG_buf .wo_nol ; 
printf(" part-no - Xs, \n qty in ascii • ?is\n", wo_complete_buf .part^no, 

wo complete buf-qty ascii); 
} " * 

} 

/* End communications with HP Sockets */ 

if {(rc - SpEnd{flags)) !- 0) 

printf ("ERROR: SpEnd returns %d\n", rc); 
else 

printf {" SpEnd was successful .\n") ; 
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ex01,h 



/* */ 

/* This ftle defines the file directories and structure for the */ 

/* example adaptors. */ 
/* V 

^ A A'lAA'A A'A A A Ar A A A A A A A A A* Ar A* A A A A A AA'AAA A-A-AA^k A A^A'AA'A^*^kA*#^***A AAA A AAAAAAAAA ^ 



/* Define the file directories. */ 

define HRPWOFILE Vusr/contrib/Sp/ref/prograros/swof ile" 
define SCHWOFILE Vusr/contrib/Sp/ref/prograras/dwof ile" 
define SCHDISPF V*isr/contrib/Sp/ref/prograras/d1spatch" 
define LOGINFO "/usertpassword" 

/* Define the structure of the work order record */ 
/* used in the datagen.c and schOlcp.c programs, */ 
/* Datagen solicits the user for this information*/ 
/* which the mrpOl process sends to schOl. */ 



typedef struct 
C . 

char wo_no[ll]; /* Work order number 

Int qty; /* Number of parts ordered 

char due_date[7]; /* Date order is due 

char part_no[17]; , /* Part number 
). wo_rec; 

/* Define the structure of the dispatch message record */ 

/* used in the schOlcp.c and sch02cp.c programs. */ 



typedef struct 
{ 

char part_no[17]; 

int qty; 

char start_date[7] ; 

char start_t1rae[5]; 

char stop_date[7]; 

char stop_time[5]; 

char wo_no[ll]; 
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} disp^rec; 

/* Define the structure of the work order complete record V 
5 /* used in the mrpOZcp.c program, */ 

typedef struct 
C 

char wo.no [11]; 
char part_no[17]; 
char qty_a$cii[18]; 
char date_complete[7]; 
) wo_complete_rec; 

/* Define the structure of the work order complete record */ 
/* used in the sch02cp,c program, V 

typedef struct 
{ 

char part_no[ia]; 
char wo_no[12]; 
Int qty; 

char date^compl ete[8] ; 
} wo_compl_s_rec; 

30 
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datagen 






V 
V 
*/ 
V 



/♦ Global Include */ 

#1nclude <std1o.h> 
#1nclude "exOl.h" 

maInO 
( 

FILE *wo_fp; 

wo rec *wo_ptr, mo buf; 
Int i; 

char 1n_buf[80]; 



wojjtr - 8iwo_buf ; 

if( (wo^fp - fopen (MRPWOFILE, "w")) NULL) 
{ 

ppintf ("Could not open work order file Ss.\n", HRPWOFILE); 
retum(O) ; 

} 



printf("Oo you want to add a new record into the work order file?\n"); 

gets(in_buf); 

if (in buf[0] !- 'y') 



for(;;) 
C 



break; 



printf{ "Enter wo_no - (up to 10 char)\n"); 
gets(in_buf); 

stmcpy7wo_ptr->wo_no, in_buf, 10); 
wo_ptr->wo_noCIl] • NULL;~ 
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printf ("Enter quantity ordered \n"); 
gets(in__buf ) ; 

wojptr->qty - atoi (in^buf) ; 

printf ("Enter part^no - (up to 16 char)\n'); 
getslin^buf) ; 

strncpyTwo_ptr->part_no, in_buf, 16); 
wo_ptr->part_no[16] - NULL; 

strcpy(wo_ptr->due_date, "891206") ; 

if((i - fwrite(wo3tr, si2eof{wo rec), 1, wo^fp) ) !- 1) 

( 

printfCfwrite error for %s.\n", MRPWOFILE); 
return(O) ; 
> 

} 

fclose(wo_fp) ; 

} 



30 



35 



40 



45 



50 



55 



10 



15 



20 



RMCinnrrn- <rFP 0456249A2> 



EP 0 456 249 A2 



APPENDIX C 



Data Definitions 



DDL is used to defina data that requires manipulations. 
These definitions are contained in a Data Definition 
(Ddef.def) configuration file. 



data definition 
"begin 
<declarations> 
END; 

Declarations 

A declaration is a statement specifying the data 
type of one or more identifiers • 

A data type is a collection of elements formed in 
the same way and treated uniformly. They 
determjlne these attributes for each identifier: 

- A set of permissible values 

- A set of permissible operations 

- Storage and alignment requirements 

The invention does not bind identifiers to any 
fixed alignment, representation, or language when 
the DDL declarations are compiled. The invention 
binds lamguages during the linlc definition 
specification* Alignment and physical 
representation of a structure in memory are 
determined at run time according to the semantics 
amd machine architecture when the structure is 
used. 

DDL data types can be: 
—Simple 
^-Structured 



Format 
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Simple Types 



Simple Data types are pre-defined types that indicate 
the format of the storage for a particular data object. 
The invention supports these predefined simple data 
types: 



Ordinal 



Boolean 



Char 



Real User-defined 



BYTE 

BIT_FIELD 
SHORT_INT 
INTEGER 
LONG INT 



BOOLEAN 
L0NG_BOOL 
SHORT BOOL 



CHAR REAL OPAQUE 

STRING LONG_REAL 



Ordinal 

Ordinal types are: byte, bit_field, short_int, integer, 
and long^int. 

Ordinal types are signed unless they are preceded with 
the keyword UNSIGNED* If ordinals are UNSIGNED, they 
can represent only positive values • 

The unsigned keyword may also change the algorithms 
that the invention uses to calculate alignment, 
storage, representation and type conversion 
requirements. For example, a short_int on an HP9000 
computer may have the values 0 ••«.65535. 

Although the actual sizes vary according to the 
machines used, these are the general effects of the 
UNDERSIGNED keyword with type conversions: 

- When the source integer's value is greater than 
can be physically represented by the destination 
type, the destination value will be set to the 
largest number that type can represent. 
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Example: 

A short_int (16 bits) with the value of 346 at the 
source that is converted to a SIGNED byte (8 bits) 
will have the value of 127. If it is converted to an 
UNSIGKED byte, it will have the value of 255. 

- When the source integer's value is smaller than can 
be physically represented by the destination type, the 
destination integer will be set to the smallest niomber 
that type can represent, 

Ex2uaple: 

A short int (16 bits) with the value of -346 at the 
source that is converted to a signed byte (8 bits) 
will have the value of -128- If it is converted to an 
unsigned byte, its value will be 0« 
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BYTE A byte type represents individuaJ characters of data as integers. This type 
is a convcaient method for denoting very small integers. It represents the 
smallest individually addressable memory clement in 8-bit byte machine 
5 architectures. The subrange of integers for the byte type on the HP9000 

computers is -128—127. 

Brr FIELD [1-321 A bit Qeld type denotes an integer that is represented by an arbitrary 

number of bits. Bit fields can extend from 1 through 32 bits. Bit Gelds can 
70 ' be signed or unsigned. The size of an integer on a given architecture is the 

largest bit field allowed Bit fields are placed in storage locations from the 
most significant to the least significant bits. 

Bit fields may not cross or straddle a word boundary as it is defmed for a 
75 particular machine archiieaurc. If a declaration causes a bit field to 

exceed the current word, the bit field is put into the beginning of the next 
word and the remaining bits in the current word are skipped 



20 
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SHORT INT Short^int, integer, and long_int types arc simple types whose ranges arc 
INTEGER determmed by subranges of the negative and positive integers. The actual 
LONG INT subranges are determined by the machine architecture on which they are 
referenced Like other ordinal types, you can modify the subrange vrith 
the keyword UNSIGNED. On the machine architectures supporting 
these data types, the short jnt has the smallest width of subranges, and the 
long^mt has the largest. For example, these data types have these 
subranges of integers on the HP9000 computers: 

SHORT INT -32,768 . . , 32,767 

INTEGSl .2,147,483,648 . . . 2,147.483,647 
LONG INT -2,147,483,648,,. 2,147,483,647 



35 



In C on the S300 and S800, integer is the same length as long^inL 

Note that where an archiieaure or language docs not possess one or .more 
of these data types, the nearest equivalent ordinal type is used instead 
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Boolean 



SHORT.BOOL 
BOOLEAN 
LONG.BOOL 



Short^booi, boolean, and long^bool are simple types that indicate logical 
values! These data types arc equivalent to the lo^cal data type in 
FORTRAN. The two possible values for these types are TRUE and 
FALSE, The representation and alignment of a boolean value depends on 
the language and machine on which it is used. 
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Char 
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CHAR A char type represents individual charaaers in the 8-bit ASCII character 
set. A character Eteral is either a single character cndosed by single 
quotation marks or an escape character, AJl character Qpes arc assximed 
to contain ASCII data. Use the byte type if a structure contains binary 
data. The particular character set representation is determined by the 
machine archiieaure where this data is produced or consumed 

STRING A string type represents a sequence of characters. The way the charaaer 
sequence is represented depends on the language that produces or 
consumes the data. Strings have an upper Emit of 1024 characters. 

The string type consists of the keyword STRING and an integer 
cootaining the maximum length of the string endosed in square brackets. 
For C the maximura length must include one extra character for the 
terminating null character. For Pascal and FORTRAN* the m a ximum 
length is the same as would be dcfmed in a Pascal or FORTRAN program. 

In C language, the string.type is a sequence of characters terminated by a 
NULL where NULL has a value of zero. The NULL terminator is 
considered part of the string. In FORTRAN, a string type is a sequence 
of diaraaers that is blank*padded to the string's masmom length. In 
Pascal, the string type is a sequence of characters preceded by an ordinal 
specifying the current length of the string. 

Note that the Pascal language on HP9000/S300 and S800 has an explicit 
string data type separate from a packed array of character data type. 
These data types are not the same thing to DDL Use the DDL string 
type for the Pascal string type. Use the DDL packed array of character 
declaration for Pascal packed array of charaaer data elements. 
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Real 
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REAL Real and long^real types represent a subset of the real numbers. A real 
LONG.REAL type is generally smaller than a long^real. The range (precision) for this 
data type depends on the machine architeauie on which the data is used. 
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User-defined 



OPAQUE An opaque type denotes binary data which the invention should not 



The opaque type is always represented by eight binary bits. The purpose 
of the opaque type is to allow unaltered transfer of binary data between 
different systems. Translating binary data (such as Programmable Logic 
Controller ladder logic programs) to suit a particular machine 
architecture would corrupt the data and prevent its being downloaded to 
its ori^nator. 

Example of Simple Data Type 

This is an example of a data definition using the simple daU types BYTE 
andLONG.BOOL: 



DATA^DEFINTION 
BEGIN 

Tl - BYTE; 

Stuff - LONG.BOOL; 

END; 
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Structured Types Stmcmrcd types arc built from simple data types or other stniourcd 

types. DDL supports two strucnired types; 

-ARRAY 

5 

-RECORD 

Pascal strucnired types may be spedfied as packed The PACKED 
spedCcatioQ tells the DDL compiler that the storage requirements for the 
jQ compooems of the given array or record have beca or should be 

opumized. The particular storage layout and arignmcnt algorithms 
depend on the lauiguage and nuchinc architecture that pn>duces or 
consumes the array or record. The PACKED spcn'ficafion has no ciTect 
oa C or FORTRAN elements. 



75 



20 



30 



ARRAY 



An array coosisu of components that are all the same type. You can use 
other structured types to build strt^ctures such as muIti-dlmensional arrays 
and arrays of records. 



Format 

identifier - [PACKED] ARRAY [< dimensions >] OF <typc> 

25 where: 

type Simple types, arrays, records, or other previously drfirvcd DDL 
types 



The dimension spcdfication indicates the maximum number of elements 
for a given dimension of the array. DDL always assumes the lower bound 
of one for each dimension of an array. The dimension length may be any 
integer constant You can access each element of an array with the index 
of the array element. 

35 An array is said to be mutC dimensional if its definition contains more 

than one dimension. Hie invention defers its assumptions about th 
order of the array element until a spedftc language ts cwund to the source storage 
and destination data struaures during a data manipulation specification. 
The spedflc language determines how the multi-dimensioned arrays are 
stored in memory (row-major or column-major). FORTRAN b 
column-major. C and Pascal are row-major. 



40 



45 



50 



55 



72 



BNSDOCID:<EP 0456249A2> 



EP 0 456 249 A2 



RECORD 

A record is a sequence of named members that arc nd necessarily of the 
same type. Each member is called a Geld of the record and has its Ofwn 
identifier. Fields in different records can have identical names but 
represent difTereat objects. You access a Geld b a record with the 
appropriate GeJd selector (".')• 

Fields are placed in physical storage in their order of dedaration in the 
record defmition. A field's oflsct is the distance from the start of the 
record to the begiiming of the Geld. 

Format: 

idcntiCcr - [PACKED] RECORD OF[<Gelds>] 

A Geld deGniiion consists of an identifier, a colon, and a type. Recursion 
in any form is not allowed. You may not declare a record clement which 
has itself as the type. 



name info - RECORD OF [ 
first 
middle 
last 
]; 

addr info - RECORD OF [ 

street : STRING[80]; 

city : STRING[30]; 

state : STRING[16]; 

zip : INTEGER; 

]; 

person_info - RECORD OF [ 
name 
addr 
married 
numklds 
kidnames 



Example 

This example shows records with members of simple and structured types. 

STRING[30]; 
STRING[30]; 
STRING[30]; 



name^info; 
addr_info; 
BOOLEAN; 
BYTE; 

ARRAY[100] OF name info; 



73 



EP 0 456 249 A2 



Language 
Dependencies 



Tabic a. I C Data Types and DDL 



HPC 
Type 


DDL 


Comments 


cfaar (ASCII) 


char 


The DDL char data type is always asswncd to cootaia 
ASCn data, not binary fmtcgcr) values. 


char (signed data) 


byte 


The DDL byte type b always assumed to contain an 8-bit 
binary (integer) value and may be signed or nnsignr-d 


onstgned char 


unsigned byte 


short 


short Int 




unsigned short 


unsigned shorc_int 




int 


integer 




, unsigned int 


unsigned integer 




long 


ioag_int 




unsigned long 


unsigned loag_int 




floac 


real 




double 


bng^rcal 




char array 


string^n] 


For transformation purposes, the DDL string type is 
always assumed to contain ASCH data. 


array 


array 


FQrthcS300and the S800, arrays are aligned by element 
type. 


strua 


record 


These are the alignment rules for records: 
S300 - nested record - 2 bytes 
S300 • unnested record - 4 bytes 
S800 - largest Held 


char (as boolean) 


short bool 


Boolean types contain one of only two values: TRUE or 
FALSE. When a DDL boolean type is used, :the xnvent 
applies the C language-imposed rules for determining if 1 
the value is true or false* ' 


int (as boolean) 


long_bool 


short (as boolean) 


boolean 


long (as boolean) 


long_bool 


enum 


integer 





(Table continues on next page) 
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(Continued from previous page) 



HPC 
Type 


DDL 

Type 


Comments 


bit fields 


bit^^field 


C supports a bit field dau type, DDL docs noc explicitly 

support IZUS Ual3 type si prcocot* Arfw** ******* m^f*^^ 

idealized bit field type witb the following tssumpdons: 

Within a record, a bit^field's size remains what it is; it is 
not assummed to be rounded up to any l>ytc boundary. Its 
alignment is considered to be 1 bit. 

Within an array, a bit field's size is assumed to be 
rounded up to the nearest 8. 16. or 32 bits. Its alignment is 
atoimed to match this rounded-up size. 



There is no language counterpart for the DDL opaque data type. Tne 
indention • will not perform transformations on this type- Its reprcsenUtion 
is always an unsigned 8-bit octet. An opaque data type is assumed to 
bc^ at the next byte boundary. 



T^ble C2 shows the DDL equivalents for FORTRAN 77 data types. 
Table 5-2, FORTRAN 77 Data Types and DDL 



FORTRAN T7 


DDL 

Type 


Comments 


Logical*2 


boolean 




Logical*4 


long_bool 




Integcr*2 


short iat 




Integer*4 


mtegcf 




Integer*4 






Real*4 


real 




Realms 


long,Tcal 




Charaaer'N 


string[n] 


For transformation purposes, the DDL string type is 
always assumed to contain ASOI data. 


Array ^ 


array 


For the S300 and S800, arrays are aligned by element type. 


Common Blocks 
Equivalenced data 


record 


These are the alignment rules for records: 
S300 • first field 
S800 -first field 
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Table C-^^ows the DDL equivaJcnti for Pascal data types. 
Table C-3 P«tcil Data Types and OOL 



Pascml 

Type 



Boolean 



Bookaa 



DDL 
Type 



short bool 



boolean 



70 



Booleaua 



-128..127 



Shortinc 



75 



Integer 



Integer 



Char 



20 



ml subrange 



int subrange 



25 



30 



lon^bool 



byte 



short int 



Comments 



Boolean types contain one of only two values: TRUE or 
FALSE. When a DDL boolean type is used, h the invention 
applies the Pascal langtiage-imposcd rules for determinisg 
if the value is true or false. 



The DDL byte type is ahvmys assumed to contain an 8-bit 
binary (integer) value and may be signed or unsigned. 



There is no Pascal shortim type on the S300. S300 int 
subrange is ■3Z768..»32767. 



integer 



lQng_E 



mt 



diar 



bit 6eld 



ansxgncd bit_field 



35 



40 



Real 



Longrcal 



real 



longrcal 



There g no Pascal long_int type on the S800. 



The char type is always assumed to confatn ASCII data, 
not binary (Integer) values^ 



invent ion 



Bit fields may be from 1 to 52 bits in length. Ihe 
uses Pascal's rules for aligning and sizing bit 5elds. Sizing 
and afigninffnr rules for bits fields are shown below. 

Independent bit fields or those contained m an unpadced 
record or arrayt 

S300 • Size is rounded op to the nearest 16 or 32 bits; 
aligmnmr is the san» as the resulting size. 
S800 - Size is rounded up to the nearest 8, 16, or 32 bits; 
afignmmf is the same as the resulting size. 

Bit fields that are elements in a packed array. 
S300 • Size and aJignmcrtf are rounded to the nearest 1, 2, 
4, 8, or 16 bits. If the bit field is greater than 16 bits in size, 
afignmm is 16 bits and size is rounded up to 32 tnts. 
S800 - Size and alignment are rounded up to the nearest 1« 
2, 4. 8, 16. or 32 bits. 

Bit fields that are elements in a packed record 

S300 - Size is the acnsal size of the bit field and alignment 

islbiL 

S800 • Size is the actual sac of the bit field and angnrnffiu 
islbit 



(Table continues on ucn page) 
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(Continued from previous page) 



Pascal 

Type 


DDL 
IVpe 


Comments 


String(N) 


string^o] 


For iransformation purposes, the string type is always 
assumed to contain ASCII data 


Array 


array 


Tliese are Ihe alignment rules for arrays: 
S300 - nested array - 2 bytes 
S300 - unnestcd array - 2 or 4 bytes 

(2 if the clement size is 2 bytes or less) 
S800 - arrays arc aligned by clemcnl type 


Record 


record 


T\tm*^ fhi» Alirament rules for records 
S300 - nested record and packed - 2 
S300 • nested record and unpacked - 1 or 2 

(1 if record size is 1 byte or less) 
c^rwi - tinn(><tpd recnrd snd Dscked - 2 or 4 

(2 if record size is 2 byics or less) 
S300 - unncsled record and unpadxd - 1, 2, or 4 , 

(1 if record size is 1 byte or less, 2 if record 

sizeis2or less) 
S800 - largest field 


SETS 




DDL does not support enumerated types or sets. 
However, since Pascal represents these types as an ordinal 
type, you can use DDL to defme a reasonable facsimile. 
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Example 

This is an example of a string as deOned in DDL, C, FORTRAN, and 
Pascal 



DDL 



Reel -RECORD OF [ 
bl : BYTE; 
si : SHORT INT; 
a3 : ARRAYI33 0FCHAR; 
11 : INTEGER; 

]; 



20 



25 



30 



struct { 

char bl; 

short si; 

char al[3]; 

Int il; 
) reel; 
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FORTRAN 



s 


c 


Elements of structure 


TO 




CHARACTER*! bl 
CHARACTER*3 al 
INTEGER*2 si 
INTEGER*4 i 1 




c 
c 


Use th i s to be sure that the f i rst el ement of the 
structure i s on a 4- byte al ignraent 


75 




INTEGER*4dl 




c 


Call SAR with this buffer 






CHARACTER*30 cbl 


20 




EQUIVALENCE (dl.bl.cbl) 
COMMON /reel/ b, si, al, il 


25 


Pascal 



trecla- RECORD 
bl : char; 
si : shortint; 

al : packed array[1...3] of char; 

11 : integer; 

END; 

buff : array[l. .200] of char; 
(call SAR using buf) 

trecl - RECORD CASE INTEGER OF 

1 : (rl : trecla); 

2 : (buf : buff); 
END; 
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Data Definition Declarations 



< dau-def-section > 

< declarations > 

< declaration > 
<type> 

< simple-typo 
<ordixials> 



< non-ordinals > 



< structured > 



s» DATA^DEFINrnON BEGIN < declarations > ESD 

s« <declanmon> 

I <declaradons> <dtdwradon> 

r«" <idawfier> 9 <type> \ 

s « [PACKEDJ <mtcmrtd > 

I <simpleHype> 

I [FACKEDJ <idatdfier> 

z « /UNSIGNED/ < ordinals > 

s- SHORT INT 

I - INTEGER 

I LONG INT 

I BYTE 

I Brr^FIELD [ <bU4ength > ] 

= - SHORT BOOL 

I BOOLEAN 

I LONG BOOL 

1 CHAR 

I REAL 

I OPAQUE 

I LONG REAL 

I STRING [<&ngrt>l 

n« ASRAY[ < dimensions > ] OF < type > 

I RECORD OF I <fields> } 



< fields > 

<field> 

■< dxnezisions > 

<Iengch> 
<bic-Iextgth> 



<field> ; 

<fields> <JUId> ; 
<idenitfier> : <type> 
<latgth>^ 

<4Smensions> » <length> 

<dedmaI<onst> 

1|2|-|32 
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fPPgyPTX D 



Data Manipulations 

After the data struct\ires to be passed between 
applications in DDL, are defined, the Data Manipulation 
« Language should be used to define the manipulation, the 
invention must perform on the structures. These 
manipulations are defined in the Data Manipulation 
Definition configuration file (Dman-def) . They 
reference the data definitions defined in the Data 
Definition configuration file (Ddef .def) . 

DML has two declaration parts: 

- The header section 

- The manipulation statements section 
FORMAT 

DEFINE MANIPULATION <identif ier> ; 
SOURCE"datA: <identifier> 
DESTINATION_data: <IDENT1FIER> : 

BEGIN MANIPULATION 
cmanipulation statements>; 
END_MANIPULATION ; 

Header Section The header section defines: 

- The name of the manipulation 

- The' name of the DDL definition of the 
source data 

- The name of the DDL definition of the 
destination data 

Manipulation Statements Section 

The manipulation statement section contains the 
instructions for translating from one data structure 
format to another. The instructions or statements are 
executed sequentially in their order in this section. 

There are two kinds of statements in the declaration 
section: 

-Assignment statements 
-Move statements 
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Assignment Statement 



Assignment statement assign literal vaJues and operators for accessing 
arrays and stniaures. 

Format 



70 



75 



20 



smicrure « value; 

Yon use assignment statements primarily to set a default value (contfanr 
or Uceral) for a destination field 

The literal value assigned to the destination ileld may reference only the 
destination DDL data type which must be a simple type or an array of 
simple type If the destination field is an mgnalificd array, the literal 
value specified sets all the elements of the array. 

Tlie literal value must be appropriate for the destination Geld type. For 
example, a destination field that is an integer type must be assigned a 
literal that is an integer. The literal value must also physically fit within 
the legal range of values for the destitution type. For example, a signed 
byte as the destination type must be assigned a value between -12S and 
127, Any other value is illegal. 



25 



30 



Floatins-Point 



35 



Constants 

Coftstants are primary expressions whose literal or symbolic values do not 
change. Each constant has a value and a type determined &om its form. 
inventaori j^uates constants at compile time. 

Cottszants can have these values: floating point, integer, charaaer, and 
string literal. 

Floating-point consunts represent floating-point values. They consist of a 
coefCdcnt and an optional scale factor (exponent). The coeffident is a ' 
decimal point with at least one dt^t preceding or foQowing it. Tlie 
optional exponent is introduced by either the £ (or e) charaaer or the L 
(or i) charaaer (for an extended floating point number) followed by the 
scale faaor. Maximum and minimum values and significant disits det>end 
on the particular machine architeaure used. 



These are examples of floating-point constants: 

3.14159265358 J1459c + 1 7£5 

S76 Z 
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Integer 
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/ Integer constants represent integer values. This constant consists of a 
sequence of digits with an optional preceding siga character. 

Use the L suCix to force a constant to a bng integer (example: 37L or 
371). Begin hexadecimal constants with Ox (the x charaaer case does not 
affca its value). You can force hexadecimal constants to long integers 
with the L sxifGx. Examples of hexadecimal constants are: 

OxAAF OxbAd 0X1AF7L 

Character Character constants are any characters except the single quote O, the 

double quote ("). and the backslash (\). Use the backslash character (\) 
followed by up to three octal digits for octal escape sequences. Note that 
this octal representation docs not require a leading zero and you can use 
fewer than three digits. The two character constants below arc identical; 
each represents the decimal value of 68: 

•D' and •\104' 

Use the backslash character followed by an x and up to two hcxadcdmal 
digits for hexadecimal escape sequences. The two character constants 
below are identical: 

•C and •\x4y 

Id both oaal and hexadecimal representations, the backslash and 
following digits arc converted bto a single 8-bit character which Is stored 
in the charaaer constant. 

The escape sequence representation of new line, single quote, bac ksl a sh, 
and double quote special characters are \n, \\ \\, and V respectively. 

String Literal A string Uteral constant is a sequence of zero or more characters enclosed 
in double quotation marks ( * and " ). 

Use the escape character 
sequence to represent the double quote charaaer appearing in a string 
literal as in the example below. 

" Samaniha said VShorten the semcnce\" * 

Consecutive double quotation marks represent null strings. 

Note that you cannot escape the escape character it se lf . You must 
represent it as a hexadecimal or octal constant (example: \xSc) 

Hie inventinn determines the type and representation of the string by the 

context in which it is used and stores it correctly for its given language and 
machine architecture. 



83 



EP 0 456 249 A2 



Move Statements Move statements let you move a source struaure into a destination 

structure with a transparent correction for language and machine 
architecture Incompaiibilities. The move statement performs these tasks: 

- Corrects for dirTcrcnces in the languages of tlie source and des- 
tination stmaures 



10 



15 



- Corrects for differences benveen the machine architectures that 
produce the source and consume the destination structures 

- Provides type conversions between the structure components 
where necessary. 

Format 

MOVE <sourcc> TO <dest> [USING "<fint-descr>T 



The move statement consists of the keyword MOVE, the data source 
structure, the keyword TO, and the data destination structure. Use the 
20 optional keyword USING followed by a format descriptor to convert 

between numeric and ASCII structure components. 

Source and dest refers to the name of any structured type or any element 
(Geld) of a structured type. The source and destination structures a.re 
25 defined with DDL in the Ddef.def (He and specified m the header s&v.don 

of the data manipulation definition. Note that destination to destination 
moves and source to source moves are not allowed. 



Array Subscripting 

AU elements of the array will be moved if the array is not subscripted. 
You can make a subscripted reference to a single element m an array. 

DML uses the language declared in Link.def to determine the storage 
method of the individual elements of an array. Both C and Pascal store 
their array elements in row-major order. This is the opposite of 
FORTRAN which stores array elements in column-major order. The 
link Definition file (Link.deQ icts you select Q Pascal, or FORTRAN as 
the language that determines the storage of multi-dimensionai arrays in 
the source and destination DDL data definitions. 



Structure Members 



You can move the entire structure by specifying an anqaalified structure 
name. You can move a subset of the structure by using the field selector 
operator (.) to qualify the struaure. 

This is the convention that the move statement uses to determine which 
source struaure components are mo\xd into which destination struaure 
components: it converts any component (Held) in the source structure 
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that has a name identical lo a destination stniaurc component (5eld) to 
the appropriate destination component type and then moves ic This 
definition can be applied in a nested fashion, that is, the components of 
structured components also follow the same rules. 

The move sutemcnt ignores component names ca s ting in the source but 
not the destination struaurc. The move sutemcnt i ni t ia ltz e s component 
names existing in the destination but not the source structure to default 
values appropriate for the rypc. 



75 



name infol - 



20 



25 



name info2 - 



30 



misc struct 



35 



RECORD OF [ 
first 
last 
middle 
ssn 

3; 

RECORD OF { 
last 
middle 
first 
ssn 

]; 

. RECORD OF [ 
rdata 
Idata 



40 



Example 

These are DDL definitions for source and destination dau structures. 



string[15]; 
string[30]; 
string[153; 
array[9] OF char; 



: stringC30]; 

: char; 

: string[20]; 

: long_int; 



real ; 
integer; 
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source - RECORD OF [ 

rec^size 

descript 

rec^data 

com_struct 

differenti 

1; 

destn - RECORD OF [ 

rec_type 

rec^size 

rec_data 

com_struct 

different2 

]; 



short int; 
STRING[30]; 

array[10,5] OF integer; 

misc^struct; 

name infol; 



: char; 

: longjnt; 

: array[10,8] OF STRING[20]; 

: misc^struct; 

: name info2; 
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These arc cjcamples of DML move sutements moving the source data to 
the dcsunation data defined above. 



HOVE source TO destn; 

HOVE source-differentl TO destn. differentZ; 

HOVE source. com_struct*rdata TO destn. com^struct.idata; 

HOVE source. descript TO destn. rec_datatl »8] ; 



10 



Figure Dl shows what happens when you move jourcc to destn. 
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artt22 



MOVE source TO destn; 
source destn 



rec_size • 
(Jescnpt 

f Bc.data 

com^struct.fdata ■ 
com_struct-idata - 
difterentl.fifst 
differentLlast 
differentljmddle 
differ enttssn 



rec.type 
rec_size 
rec_data 
* com^staicUdata 
► com^stojcl.idata 
different2Jast 
dtffertnt2.middle 
different2.first 
differ enl2.S5n 



Figure Dl Move Statement Example 1 
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Fia . D2 :hows what happens when you move the Geld sourccdilTcrcnU 
to the dcidnation field destn-difTcrcnil. 



TO 



75 



art123 



MOVE source.differenti TO destn.different2; 
source destn 



20 



rec^size 
descnot 
fec^data 
cotn.struct.rdata 
com^^strucl.fdata 
differentl.first 
differentl.last 
differcnttmiddle 
dif1er«nt1.ssn — 




rec^type 

rec_Size 

fec^data 

com^structJdata 

com.struct.idata 
' diHerentSJast 

different2.middl© 
• differentS.fifst 
. different2.ssn 



25 



Fig- D2 Move Statement Example 2 

Fig.D3 'shows what happens when you move the oim.stnictxdau field 
is the source structure to the com^stmaidata field in the destination 
structure. 
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MOVE source.com_struct.rdata TO destn.com_struct.idata; 




source 




destn 




aftl24 


dascriQt 
fac_data 

com.struct.fdata - 
com.structJdata 
differ •ntl first 
difftrtfiaiast 
differ entl.middle 
diffefenn.ssn 




rec_type 

rec.size 

rec.dau 

com^stiuctJ'dala 

com.^tructjdata 

different2Jast 

diflerentZnuddie 

difter«nt2.ftfst 

different2;.ssn 















Fig. D3 Move Statement Example 3 
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. For exaibple^l&e move 

^ztfmr^K handles type conversions between fields with diflereat n nmeri c 
types and between ASCII and numeric types. 

Refer Co the following tables for the nxles for these data type convenions: 

- Boolean (boolean to boolean, ordinal to boolean) 
• Numeric to numeric 

- Floating point (integer to floating poixit and floating point to to- 
legcr) 

- ASCn to numeric and numeric to ASCII 
Bool63n Typ6 liable D-4 • shows tne action for boolean type coavcrsioas. 

Conversions 



Table I>-4 BoolQan Type Conversions 



Source Field Type 


Destination Field 
Type 


AcUoa 


Ston boolean 
Boolean 
Long boolean 


Boolean 


If the source field type is a boolean, the destination field 
type must be a boolean. 


Integer 


Boolean 


The source field type language determines whether the 
btegcr type is true or false.* For examf^ if the source 
language is Pascal, a zero value means FALSE is placed into 
the destination field; a value of one places TRUE in the 
destination field. Any other value yields an unpredictable 
destination field value with a warning logged at the source 
node. If the source language is Q a value of zero is FALSE 
and a non-zero is TRUE. 



DM L Type 
Conversions 
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Numeric to Numeric 
Type Conversions 



Nmncric to numeric type conversions involve handling the c^crcnces in 
the sizes and the signs of the source and dcsunation dau Gelds. 

Table D-5 stows tte roles in converting from one numeric 

type to another numcnc type. 



TS^blo M Numeric to Numeric Type Conversions 


Numeric Type 


Source/Destination Size DifTcrence 


HP Sockets Action 


Integer 


The value of the source is larger than the 
destination can hold 


HP Sockets sets the destination to the 
manmum value the destination can hold. 

Example: If an unsigned byte holding 250 
is moved to a (signed) byte» HP Sockets 
sets the value in the byic to + 127^ 




The value of the source is smaller than 
the destination can hold 


HP Sockets sets the destination to the. 
minimum value the destination can hold. 

Example: If a (signed) byte holding -46 is 
moved to an unsigned byte, HP Sockcu 
sets the value in the unsigned byte to 0. 


Floating point 


The source's value is too large to be 
represented in the destination (overflow) 


HP Sockets sets the destinatioa to the 
maximum value the destination can hold 

Example: If the source is a long^real with 
a value ot o3ji ana xi is movca lo a 
real (on the S300), HP Sockets sets the 
destination to 3.402^-1-38 because that 
long^reai value cannot be represented in 
a (S300) real 




The source's value is too small to be 
represented in the destination (underflow) 


HP Sockets sets the destination to zero. 

Example: If the source is a long^rcal with 
a value of .l£*300 and it is moved to a 
real, HP Sockeu sets the destination to 0 
because *l£-300 cannot be represented in 
a real. 
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Floating Point Type These arc the general rulcs for conversions between niimcnc types 
Conversions Gntegcr and noating poini) : 

• If the value of the source field is greater than can be represented 
physically by the destination, the destination is set to the mazisiazn 
permissible value (infinity if supported by the architecture), A run 
time warning is generated and logged. 

• If the value of the source is smaller than can be represetucd 
physically by the destination, the destination is set to the minimum 
permissible value (negative infiiucy if supported by the architecture). 
A run time warning is generated and logged. 

T ^Xe D-6 * demotistrates the rules for integer to floatingpoint and Qoaiing 
point to integer type conversions. 



Tfeible 0-6 'Floating Polrrt to Floating Point Type Convtrslons 



Sonrce FlddT^pc 


Destinatioa Field Type 


HP Sockets Action 


Integer 


Floatingpoint 


If the integer's precision is greater than a real type can 
represent, the least significant di^ are lost 


Floating pomt 


Integer 


HP Sockets truncates the fractional part 
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ASCII and Numeric 
Type Conversions 



You can convert a numeric type to ASOI and the reverse if one of the 
fields is a string or char type and the otlier is an integer or floating point 
type. Table .D-7 shows these conversicns. 



TaHp D-7 ASCII and Numeric Type Conversions 



Source Field Type 


Destination Field l>pe 


AcUoa 


Numeric 

Integer or 
floating point 


ASCIL 

Stringer 
char array 


Source value is convened to an ASCII format generic to the 
numeric type. If the destination field is not large enough to 
hold the ASCII data, asterisks (*) arc put into the field. 


Numeric: 

Integer or 
floating pobc 


ASCII: 

Mula- 

dimensioned 
array of char 


The number's ASCII representation is placed into each row 
or column of the destination array according the destination 
language. That is, the array is filled by rows if die 
destination language is C or Pascal, and filled by columns if 
it is FORTRAN. 

If the source field is an array, each clcmcat of the source 
array is 1) processed in row-major order for C and Pascal 
and column-major order for FORTRAN, 2) type converted 
to ASCII, and 3) its ASCII rcprcscnudon placed in the 
appropriate row or column of the desUttadoa array. 


ASOI: 

String or 
char array 
(Only decimal, oaal, 
hexadecimal, or sign 
charaaers allowed. For 
floating point £, e, and 
dot (0 allowed.) 


Numeric 

Integer or 
floating point 


Source value is converted to numeric type. If the 
destination Held cannot contain the numeric value, the max 
or min values are used depending on the value of the source 
field. 


ASCtL 

Multi- 
dimensioned 
array of char 
(Only decimal, octal, 
hexadecimalt or sign 
charaaers allowed. For 
floating point £, e, and 
dot (.) allowed.) 


Numeric 

Integer or 
floating point 


The number represented in ASCII m the source is placed 
into each row or colunm of the destination array according 
to the destination language. That is, the array is filled by 
rows if the destination language is C or Pascal, and filled by 
columns if it is FORTRAN. 

If the source field is an array, each element of the source 
array is I) processed in row-major order for C and Pascal 
and column-major order for FORTRAN. 2) type converted 
to numeric, and 3) the number is placed in the appropriate 
row or column of the destination array. 


Ascn 


Numeric array 


Each element of the array is set to the ASCII value. 
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Example 

This is an example of numeric to ASCII type conve raons . This example 
shows moving the date consisting of three integers into an ASCU string 
and an ASCII array of char. 

This struaure in a C program contains information about an operator that 
includes the date employment started: 

struct { 

char Operator[20]; 

Int Month; 

int Day; 

int Year; 
} id, rid; 



The manipulation that we want to do is to move the operator and date 
tDformation into both of these 2 structs: 



struct { 

char 0perator[15] ; 

char Date[ll]; 
) rl, rrl; 

struct { 

char Operator[15]; 

char Date[20]; 
) rla, rrla; 

These are numeric to ASQI conversions, moving integers from stmctore 
id into a charaaer string (in structure rl) and an amy of char (structure 
rla). 

These are the DDL data definitions for the three structures: 



DATA^DEFINITION 
BEGIN 



/* Define structure ID as a record named 
1nput_data in DDL */ 

1nput_data - RECORD OF [ 

^Operator : STRINGC20]; 

Month : INTEGER; 

Day : INTEGER; 

Year : INTEGER; 
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/* Define structure id as a record named report 1 
in DDL */ 



reportl - RECORD OF [ 
Operator 
Month 
Slashl 
Day 

SlashZ 
Year 

]; 



STRING[15]; 
ARRAY [2] OF CHAR; 
CHAR; 

ARRAY[2] OF CHAR; 
CHAR; 

STRING[5]; 



/* Define structure rla as a record named 
reportl a in DDL */ 



reportla - RECORD OF [ 
Operator 
Year 
Dotl 
Month 
Dot2 
Day 

]; 

END; 



ARRAYC15] OF CHAR; 
ARRAY[4] OF CHAR; 
CHAR; 

ARRAY [2] OF CHAR; 
CHAR; 

STRIN6[3]; 



i_to_reportl is the manipulation definition for moving the input data 
structure into the reportl struaure. This displays the operator name as a 
string, and the date in American format (mn/dd/yy). It uses the 
assignment statement to set the characters Slashl and SIash2 to '/*. 

DEFINE_MANIPULATION i_to_reportl ; 
Source_Data : input_data; 
Destination_Oata : reportl; 

Begin_Manipulation 

move input_data to reportl; 
reportl. Slashl - '/' ; 
reportl. SI ash2 - '/'; 



End_Manipulation; 
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i_to_reportla is the manipulation dennition for moving the input data 
structure into Che rei>ortla structure. This displays the operator's name as 
an array of char, and the date in European format (yy.min dd). It uses the 
assignment statement to set the characters Dotl and Dot2 to 

DEFINE_MANIPULATION i^to^reportla; 
Source^Data : 1nput_data; 
Destination_Data : reportia; 



Begin_Hanipulation 

move input_data to reportia; 
reportia. Dotl • 
reportia. Dot2 - 

End_Manipu1ation; 

If structure id is initialized to these values: 

strcpy{id.Operator, "John Skupniewicz") ; 
Id.Month - 1; 
id.Day « 30; 
id. Year - 1990; 

The convened structure will display in Reportl as: 

Operator is John Skupniewi 
Date is 1 /30/1990 

and in Reportia as: 

Operator is John Skupniewic 
Date is 1990.1 .30 
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ASCII Format You can control the format of ASCII values by means of a format 

descriptor spcdfied with the move siatemenL The format descriptor 
controls type conversions at either the source or the d estina tion. When 
5 the ASCII data is the source field, the format descriptor describes the way 

the source data is read. When the ASQI data is the destination, it 
describes the way it should be generated. 

Format ASCII values with the keyword USING followed by a format 
10 descriptor as in this example: 

MOVE <50urce> TO <dest> [USING •<fmt-descr>"] 



Refer to the Move Statement description for explanation of the 
75 components in the move siatemcnt. 

Valid formats are: 

%d Decimal integer (signed or unsigned) 

20 Unsigned decimal integer 

%o Octal integer (signed or unsigned) 

%x Hexadecimal integer (signed or unsigned) 

%[nxji]f Floating point number in the form [*]i iiLflI f 

%[mja]e Floating point number in the form [-]axuue[-]xx 



25 



30 



where: 



Designates the field width in charaacrs including 
any signs or decimal i}oint 
Designates the precision 



m must be greater than n. 

m and n are optional. If they are not spcdfied, m has a default of 
14 and n has a default of 6. If the destination field cannot hold a 14- 
character width, the width is decreased starting with the digits to the 
right of the decimal and continuing to the digjts to the left of the 
decimal if necessary. A warning message is issued. 

Example 

This is an example of using a MOVE statement to conven a buffer 
from a real type to an ASCII type using a real number format descrip- 
tor 

HOVE bufferl.real TO bufferZ.ascli USING "Xie.Zf" 
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Treble I>7 clesaibes results of other aaions in fonuatling ASCII data 



Table D-7 ' Formatting ASCII DaU 



Actioa/Coadltloo 


Result 


Source d^udocs ooc oiatch the format spedfied 


No conversion performed Warning message is generated. 


Fontsat descriptor left out of the MOVE 


Default formau used: 

%d for ASCII to ordinal and ordinal to ASCII 
%14.6f for ASCII to real or real to ASCII 
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Language 
Specifics in tlie 
Move Statement 



la addiuoo to type conversion, the move statement also resolves the 
difTerences in the way difFcrcnt languages represent simple and smicrurcd 
types. For example, while the C language represents FALSE as any zero 
value and TRUE as any non-zero value, HP Pascal represents FALSE as 
zero and TRUE as one in the rightmost bit of a byte. 

When both the source and destination fields are boolcans, MOVE 
coovcrts data as appropriate for the language bound to the data structure 
in the source and destination spcdflcatioa section of this data 
manipulation definition.. 



MOVE corrects for any difTcrencc in the order the elements of 
mtxlti-dimensional arrays arc stored. It uses one of two storage methods: 
row-major or column- major. In column-major storage, the first dimensioa 
of the array varies most rap'dly in terms of the sequence of elements 
stored in memory. In row- major order, the last dimension of the array 
varies most rapidly. 

When the source is a muUi-dimensional array, DML examines the 
language of the destination field for its storage method. If the arrays use 
different storage methods, the move statement converts the source array 
to the method used by the destination field's language. It moves the 
converted source array into the destination field up to the Tn a xini u Tn 
number of elements in the source or the des tina tion array, whichever is 
firsL The source array is truncated if it is longer than the destination Geld. 
If the source is smaller than the destination, remaining bytes m the 
destination arc not touched. Uninitialized destination array elements are 
set to default values. 

The number and size of elements in the source and destination arrays do 
not need to agree for proper conversion. DML accesses the source array 
clement by element according to the language bound lo it. The 
destination array is filled according to the row-major or column-major 
rules of its language. The following example in which the sourcc(sarTay) is 
in FORTRAN and the destination (darray) in C, shows this convcrsioiL 



Example 

At the source, sarray is stored in memory in this order 

sarraytlill sarray[2,l] 
sarraytl,2I sarray[2,2] 
sarray [1,3] s array [2 , 3 ] 



At the destination, darray is stored in memory in this order 



97 



EP 0 456 249 A2 



darray[l,l] darray[l,2] darray[l,3] 
darray[2,l] darray[2,2] darray[2,3] 

You made these DDL and DML dcclaradons: 

sarray • ARRAY[2,3] OF BYTE; 
darray « ARRAY[2,3] OF BYTE; 

MOVE sarray TO darray; 
This would be the result of the MOVE : 

darray[l,l] • sarray[l,l]; 
darray[l,2] - sarray[l,2]; 
darray[l,3] - sarrayn»3]; 
darray[2,l] « sarray[2,l]; 
darray[2,2] - sarray[2,2]; 
darray[2,3] - sarray[2,33; 

Declare both the source and destination as one-dimensioaal arrays to 
place the source array elements into a destination array ^^vhBe retaining the 
source array in its original memory order. 

MOVE takes care of any alignment dirfcrenocs induced by language or 
architecture. 
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Data Manipulation Language Syntax 



< maxiip-def-sccdoa > - — 

< mam-body > r« 
<sourcc-spcc> 

< dcst-spec > r — 

< statement-sect > r « 

< statements > =- 

I 

<sutcmcnt> r« 
I 

<xia£ion-statement> s» 
<.movc-statemciit> r"» 

< expression-statement > n • 

I 

< postfix-expression > 

I 

I 

< primary-expression > »m 

I 
I 

<fi3it-descr> n — 



<real-<lescr> 
<width-len> 
< digit-len > 



DEFINE^MANIPULATION <id£nnficr> ; <n%am'bo<fy> 
Ksourc^-spco <d£st'Sp^c> <stat£maU'Scct> 
SOURCE.DATA: <id€niifier> ; 
DESTINATION.DATA: <uUTUifUr> ; 

BEGIN^MANIPULATION <sxmmaits> END^MANIPUIATION 

<stnianent> ; 

< jtfltcrTWTicr > <siatcmeni> 

<jiation-stai€ment > 
Kmcve-statement > 

MOVE <pos:fix'<xpfxssion> TO <posifiX'<xpression> 
/USING * <fmt-dcscr> '/ 

<postfbi'<xprcssion> = <constant> 
<postfix'€xprcssion> = <struigMieraI> 

<pnmary^ression > 

<postfiX'€xpresswn > [ <pnmwy^ression> ] 
<pcstfiX'€xpression> . <idennfier> 

<identxfa'> 
<consami> 
<,saing<onstant > 

%d 
5bo 
%x 
%u 

%f<real'dcscr>]t 
%[<rt{d-dcscr>]t 

< width-Un > . < digit-ien > 

<dccwuiI<onst> 

■ <dedmal'<OTxst> 
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Lexical Elements 



< token > 



< identifier > 

I 
1 

<noiidigit> 

<dipt> 

<constaiit> 

I 
I 
I 

<floadxig-pt-coiist> s- 

I . 

< fractioa-coast > n — 

! 

<aq>-part> * s« 

I 

< digit-scqucacc > - « 

I 

<sign> n« 

<inieger-const> s« 

I 

< decimal-const > 

I 

< hexadecimal-const > n« 

I 



<ccvinanr> 
<opaxuor> 
<ptmcaumon> 

<nofui2git> 

<idenxifier> <ncruilpt> 
<idendfier> <dl^t> 

any character from the sec ^ [a^l [A^] 

0|1U|9 

<flo<mng-pt<onst > 
<int€ger<onst> 
<charact€r<onst> 
<smng^iterai> 

[<sipt>} <fracticn<onst> [<Gefhpan'>] 
[<siff%>J <£pt'Sequence> <cqypart> 

[<digit'Sequ€nc€>} . <digit'Sequa%ce> 
<digi:-sequ€nc4> . 

E [<sipi >] < digit-sequence > 
L [<sign > J < digit-sequence > 

<digU> 

<dxgii*sequence> < digit > 
+ I- 

f<sipt>J <decimal<onstant> [<suffix>J 
[<siffi > J <hexadedmal'Constant> f<suffix>J 

<ncnurv^git> 
<dedmai<onstant> <digit> 

OX <heX'<Ufft> 

<hexadedmat<onstara> < hex-dipt > 



< nonzero-di^O 



112U19 
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70 



75 



20 



25 



< hex-digit > n = 
<sufBx> 

<char5ctcr-con&t> z« 

< c-dtar > s = 

I 

< escapcd-ciiaractcr > :: * 

< string-literal > 

< s-char-5equcncc> 2' 

I 

<s-char> s" 

I 

< operator > 

< punctualor > 



any character from the set: 
0123456789 
ft b c d e r 
A B C D E F 

I|L 

' <c<har> * 

any character except • or \\ 

< cscapcd^chamcter > 

V V \n \ddd \xdd 
* [KS-char-scquence >] * 

<s<har'S€quence> <j'Char> 

any charaaer except * \\ or \n 

< escapcd<haracur > 

One selected from the set: 
One selected frmn the set: 

[ 1 : ; 
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APPEMDIX E 



Pseudckrode 



headeTjojodii ) 

Ofck if arTuasnts p«Med in are IcysL. 

If cdr wrsion ntiebers mrm not compatible 

Error 
End?f 

Sat up olobal variablac ufth values pataed Into this routine-- 
tar9«t_buffar pointer, octets avaUable count, target langue^e. 

Initialize global vara for type attribute start and length, 9nd 
total target buffer length used. 

If a flag Indicating whether the trei ler^to^cdrO call haan't been done 
prior to thia call 

Error Ctuo he»der_to_^cdr() calls were done without an intervening 
tniiler_to_cdrC5 call") 
/• thia is an "error* as oppoaed to a •warning" coupled with 



Endif 

If th« target^buffer pointer is HULL 

Error 
Endif 

If target language is invalid 

Error 
Endif 

If the size of the target^buffer cannot contain the data buffer header 

Error 
Endif 

/* Assign values to the data buffer header fn target^buff er** V 
/• "Hand-aarahall" meana you wist do it directly without the •/ 
/• Sid of an KSH,^ routine. •/ 

Hand-aarshall version control id and target lang into the target^buf fer. 



a call to trailer^to^cdrC) fince we can't tell If the current 
target^ptr buffer Is a new one or the old one that didn't 
use a trailer^to.cdro call. So we'll just flag it as an 
error. */ 
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If rwt okmy 

Error 
Efrilf 

Hand-narshaU rwervation spaca for a 4-byta ASH.1 integer for tha typa 
attributt «tart. /• HOTB: thfa ia ■ non-standard ASX.I integar •/ 

If not okay " /• will fill in thia value after mtrshalltng is completa V 
Error 

Endif 

Hand-twrahall raaarvation apaca for a 4-byta ASN.I Intagar for tha 

typa attribute langth. /* KOTE; thU la a non-ttandard AS«.1 (nteoar V 

If not okay /* u(U fUl <n this value after iwrshalUng is conplete V 

Error 

Endlf 

Hand-«ar»hall tha type/langth octets of an octetstrlng Into the tenp^buffer 

to atart the ASH.1 format for the type attributes. 
Set laat^iten - not^strlng* 

Allocate a default stack fraM for array^ttack. 

Set top^of^stack fields to rac_eot*tt » 0; Initial ready • no 

/ trailerjtojcdri) 

If there is not enough space In the tea^^buffer for this type attribute ID 

Allocate ar«thar teqp_buffer and Unk ft into tha t«Bp_buffer I tat 
Endff 

If (currently open octetatring in type attributes buffer) 

Put end- of -contents octets in type attribute buffer to close off currently 

open octetstring. 
Endif 

Concatenate tenp_buf fer onto the target.buffer by copying octets froai 
the tenp.bufferCs) to the target.buffer. 

Update typeset truster t value in data buffer header with the final value. 
Update type_attr^ length velue in data buffer header with the final value. 

/* Optional Check: was array_stack waa enptied properly? */ 

Return to the caller the total nunber of octets used for narshatUng 

for all routines. 

arrayjioj:dr() 

If last_itea was string type 

If there Is not enough space In the tacop^buffer to restart octatstrlng 
in type attributes buffer 
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Allocate another ttnp^buffer end Unk ft into the tei^^buffer lUt. 
Endif 

Restart type attributes octetstring for IDs. 
Set las t_5 teat ■ not^atrlnfl. 
Endif 

If there U not enough apace fn the tasp^buffer for thia type attribute ID 

Allocate another teop^buffer and Ifnk ft fnto the teoip^buffer list 
Endff 

If there fa not enough apaca in the target^buf far for thia ASM.I data eieaient 

Error 
Endif 

If top^of_atack initial read/ ■ no 

If conpreaaion » PAOCED 

Aaafgn type attribute value to taap^buffar. 
Elae if ccnpresaion « KON£ 

A*aign type attribute value to teap^buffer. 
Else 

Error 
Endif 

Endif 

Puah new frane on array_ataclc« 

Initialize new atack fraaw field ree_couit to 0. 
Initialize new atacic fraota field Inlt.already to the imt.alreedy 
value of old top«of-staclc« 

Asvign ASN.1 data eleawnt to targe t_buf far. 

GnTay^€ndjojcdr() 
^op stack f raott f roai array^stack. 

If top_^of^st»ck rec^count « 0 /•thia was an array or array of array? ♦/ 

Set inlt.already « yea. 
Endif /* elae the array that just ended was a part of a record and 
the record haan't ended yet •/ 

If there is not enough apace in the target^buffer for thia ASN.I data eleaant 

Error 
Endif 

Assign ASM.1 data elenant to targe t^buf far. 
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bitJieldjoj:dr() 

If 50urce__ptr ■ HULL 

Error 
EndH 

If «t«rt_b(tj»«U1oo < 0 or > 31 

Error 
Endtf 

If nuB_of_bits < 1 or > 32 

Error 
Endlf 

Xf lMt_fte« w** string typt 

If th«r« Is not •noogh tp^c* in th« t«np_buff«r to rwtart octetstrfng 
in typt sttrtbut** bufftr 

ALlocats another t«p_buff«r and Unk ft into the teop.buffer l!«t- 
EUe 

Restart type attributes octetstring for IDs. 

Endif 

Set Isst^item « not^string, 
Endif 

If there is not enoogh space in th# temp.buffer for this typs sttributs ID 

Allocate another teop^buffar and link it into thm tenp^buffer list 
Endif 

Calculate nari^er of bytes ne«j«d to store bits. 

If there is not enoogh specs in the tsrget_buf fer for this ASM*1 date elsfaent 

Error 
Endif 

If top_of_st»ck initial ready ■ no 

If signed • SIGMEO 

Assign type attribute valoa to taop.buffer. 
Else if signed « tmsIGNED 

Assign type attribute value to teap^buffer. 
Else 

Erdif 

If top^of.stack rcc_ca*it "0 /• for the siwpla-typa array typa V 

Sat iw't.already « yes« 
Endif /• else this data alament was a part of a record •/ 

Endif 

Assign ASN.1 data element to target.buffer. 
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booUojcdri) 

If source j3tr » HULL 

Error 
Endif 

If bool,valu*,o COR_TRU£ and o CDR^FALSE 

Error 
Endif 

If lMt_1tM MS string xypm 

If th«r« is not «nou9n spaca fn the tcsp^buffer to restart octetstring 
fn tvp« «ctributt« buffer 

AUoc«tt another t««p_buff«r. and link it into th« teBp_buffer U»t. 
tlmm 

RMtart typ« attributes octautrins for IOt« 
Endif 

S«t l««t_iteai ■ not^itring. 
Endif 

If th«r« is not enough space in the tcnp^burffer for this type attribute 10 

Allocate another tta^^buffer and link it into the teep^btrffer list 
E«lif 

If there is not enough spw:« in the tsrget.buffer for this ASN.1 dst« eleMot 

Error 
Endif 

If top_of_stack init_already ■ no 

If OOL^type • SHORT^SOOUAH 

Assign type attribute value to te^p^buffer. 
Else if OOL.type • BOOLEAN 

Assign attribute value to tv^.buffer. 
Elss if OOL_type ■ LOHG.IOOLEAH 

Assign type sttribute value to taep buffer* 
Else 

Error 
Endif 

top_of_stack rec_count « 0 /•for the sinple-type array type V 
Set tnit^already « yes* 
Endif n else this data elesHnt Mes a part of a record •/ 
Endif 

Assign ASH.I data eleoient to target_buffer« 
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charjtoj:dr\) 

If source jjtr « NULL 

Error 
Endff 

If la»t_lt«rw«» ttrlng cyp* 

If th«r« is not •nooflh sp«:€ in th« teBip_buff«r to r»«t«rt oct«t«tring 
in typ« attributw buffer 

Allocate another twnp.buffar and Unk U into th« twp^buffer Hat. 
Else 

Restart rype attributes octetstring for IDa, 
Endif 

Sac la«t_fteni ■ not^string. 
Ertiif 

If thara la not anoufth apaca in th» tenp_buffer for thU typa attrlbuta 10 

Allocata anothar teeop^buffar and link it into tha tacp^buffar liat 
Endif 

If there ia not enough space in the targat.buffer for thia AS«*1 data element 

Error 
Endif 

If top^of_atack initial ready « no 

Aeaign typa attribute 10 to teap^buffar. 

If top^of^ttack rec.count "0 /•for the aieple-type array type ♦/ 

Set init^already ■ yee. 
Endif /* else this data element was a part of a record V 
Endif 

Awign ASH.1 data element to target^buf fer, 

intjtoj:dr() 

If aourca_ptr ■ MULL 

Error 
Endif 

If bit_length ■ 0 

Error 
Endif 

If last^itam uea string type 

If there ia not enough space in the temp^buffer to restart octetstrfng 
in type attributes buffer 

Allocate another tanp_buffer and link it into the terp^buffer list. 
Else 
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Restart type attributw octetstring for ID*, 
ErxJif 

S«t U^t^item ■ not^strfng. 
Endif 

If th«r« is not «nouQh tp«c« in th« teip_buffer for this typ« attributt 10 

AUocatt another te(Bp_buff«r md link it into the t«np_buffer li»t 
Endif 

Caleulace nosber of bytts needed to store bits. 

If there is not enough spece in the target_buf fer for this beta eien 

Error 
Endif 

If top_of^stack initial reedy ■ no 

If OOL_type - BYTE 

Asaion type attribute value to tcBp_baffcr. 
Else If OOL_type ■ SHWT^IHT 

Asslsn attribute vaiue to tcap.buffer. 
Else if OOL_type - IMTECER 

Assign type attribute value to teiqp^buffer. 
Else if OOL.type « LOHC.IKT 

Aaaien type attribute value to teap_buffer. 
Elae 

Error 
Endif 

If top_of_stacJc rec^cotnt • 0 /• for the siiple-type array type */ 

Set init^alreody ■ ye*. 
Endif /« alse this data elcnent was a part of a record V 
Endif 

Assign ASN.I data eleMnt to targe t^buf far « 

opaque j:aj:dr( ) 

If source_ptr « NULL 

Error 
Endif 

If nui^of_octeta « 0 

Error 
Endif 

If Isst^ltaoi was string type 

If there is not enough space in the tenp^buffer to restart octetstring 
in type attributes buffer 

Allocate another te«p_buffer and link it into the tamp^buffer list. 
Else 
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10 



75 



45 



50 



Restart rype attributes octttstring ior ID5, 
tndif 

Set tast^item « not^string, 
Endif 

If th«r« it not enoooft tqmcm in th« ttiH5.buff«r for thi« type •ttplbute 10 

Allocate another top^buffer and link it into th« twp^buffer lf«t 
Endif 

If there ia not enough spec* in the terget^buf f er for this ASM.1 data eleaient 

Error 
Endif 

If top_of_»tacic init^alreedy ■ no 

Aaaion type attribute ID to te«p_buffer. 



If top.of.etack rec_count -0 /• for the einple-type arrey type V 
Set init_alrearfy ■ ye«. 
20 Endif /* else thia data elataent we a part of a record */ 

Endif 

Aaaign ASH.1 data element to target^buf fer, 

^ real^to^cdr() 

if aourcejatr ■ MULL 

Error 
Endif 

30 

If bit.length • 0 

Error 
Endif 

35 If laatjteai was at ring type 

If there it not enough apace in the ta^.buffer to reetart octetatring 
in type attributes buffer 

Allocate another teep.buffer and link it Into the tenp^buffer list. 
Else 

40 Restart type attributes octetstring for IDs, 

Endif 

Set last.item ■ not^string. 
Endif 



If there is not enough space in the temp.buffer for this type attribute 10 

Allocate another temp.buffer and link it into the tesiip.buf fer list 
Endif 

Calculate nurbcr of bytes needed to store bits. 

If there is not enough space in the target^buffer for this ASN.I data element 
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Error 
Efjdff 

If top_of_it«ck fnit^alr««dy « no 

If OOL_typ« ■ REAL 

Attign-^typ* attribute value to tonp_buff«r. 
ElM if 0OC_tVP« « LONG^REAL 

AMign typ« aCtribut* v«tiM to tecrp^buff er. 
EU« 

Error 
Endif 

If top^of^«t»ck r#c_count « 0 /* for th« almpl«*typ« array typa V 

Sat fnit^aLraady • yaa. 
EndH /• alaa thfa data alamant uaa a part of s racorxS */ 
Endif 

A«al«n ASH.1 data alament to targat^boffar. 

record jU>^cdr() 

If raatrfctva^typa doaa not hava a leaal valua 

Error 
Endff 

If laat^itaa waa atring typa 

If thara ia not anough apaca 5n tha taap^buffar to raatart octatatring 
fn type attribute* buffar 

AUocata anothar tamp^buffar and link it into tha ttap buffar Hat. 
Elaa 

ftastart typa attributaa octatstring for IDs. 
Endif 

Smz laat_ite« • not^atring, 
Endif 

If thara ia not anough apaca in tha ta«ip_huff«r for thia typa attribute ID 
and tha raatrictiva^aligrtaant typa attribute 

Allocate another te«p_buffer and link it into the taap buffer list 
Endif 

If there ia not enough space In the target^buffer for thia ASM.1 data elM 

Error 
Endif 

If Init^alraady • no 

If cortpression » PACKED 

Asaign type attribute value to teap^buffer. 
Else if compression « MONE 
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AMign typm a tt pi but* value to Cenp^huffer. 

Error 
Endif 

A^ign type attribute 10 to tcBp^buffer. 

Increment top_of_stttck rec^count. 
Endtf 

Asafgn re«trictive_«U9nment typt attribute to tewp^buffer, 
AMifln ASX.1 data eleinent to target^buf fer. 

record^end^tojcdrO , 

If inlt_alread/ ■ no 

Oecreojent top_of_»taclc rec_cot«t. 

If top^of_»tack: r«c_count -0 /• mmt do thf« check hert for •/ 
Set init.alreed/ » yea, /• array of recorda to work */ 

Endif 
Endlf 

If thare U not efvxjgh space in the taraet^buffer for thfa ASX.1 data elCM^t 

Error 
Endff 

Am ton ASN.1 data element to target_buffer« 

\l3 string^tojcdri) 

If source^tr « HULL 

Error 
Endlf 

If MX_nun_chars • 0 OR 

curr_leftgth > nax^nun^ehars 

Error 
Endff 

If laat^item was atring type 

If there is not enough space in the taop^buffer to restart oetetstring 
in type attributes buffer 

Allocate another tcnp^buffer wid link !c into the tccnp_buffcr list* 
Else 

Restart type attributes oetetstring for IDs. 

Endif 
Endff 

If thera is not enough space in the tenp^buffer for this type attributt ID 
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and iiiex^rxiB_char« 

AUocatv «noth«r taip_buff«r and Unk ft fnto eha t«Mp_buffftr Kst 

Endff 

tf th«r« is not anouoh %pmc9 in th« tmrgmtjeuii^r for thfs ASM.1 data alaaHnt 

Error 
Endff 

If top_of_st«ck (nic.«lr««dy - no 

Assign typa attrfbuta tO to tcsp^buffar. 

End tanp_buff«r typa attrlbutaa octatstring. 
Assign ■ax^nLw^chars typa attributa to tcap^buffar. 

top_of_atacic rac^comt ■ 0 /* for tha sinpla-tvp* array typa V 
Sat initial r«ady « ya«» 
Endif /* alsa this data alaestnt was a part of a record V 
Endif 

Assign ASM.l data alosent to target^buf far. 
Sat l««t_!tafli « string. 

• uJntjojcdr() 

If »ocrrcaj)tr - NULL 

Error 
Endif 

If bitjangth - 0 

Error 
Endif 

If last^itaai was string typa 

If thara is not anough sp«:a in tha taap^buffar to restart octatstring 
in typa attributes buffer 

AUocste another temp^buffer and link it into the tetop buffer list* 
Else 

Restart typa attributes octetstring for IDs. 
Endif 

5«t last^itaoi • not^string, 
Endff 

If thara is not anough space in the temp^buffer for thfs typa attribute tO 

Allocate another teep^buffer and link it into the taap buffer list 
Endif 

Calculate nuaber of bytes needed to store bits. 

If there is not enough space in tha target.buffar for thfs ASII.l data el«Mnt 
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Error 
Endif 

If top_of_5C»ac 1n<t^alr»»cty • no 

5 

If ODL.tYP* - U_BYTH 

AMtfln type attribute value to teop^boffer - 
Else if OOL^rype • UJHORTJNT 

AMicn ettributt value to tewp^buffer, 
70 EU« a OOL_type ■ UJKTEGER 

Asaifln type attribute value to terp^buffer. 
Else If OOL_tYpe « U^LOKC_lMT 

Assign type attribute value to. te(rp_buffer. 
Else 

75 Error 
Endif 

If top_of_8t»ck r«_count - 0 /•for the sf«ple-t>pe srray type •/ 
Set init^st reset/ ■ yes, 
20 Ertiif /♦ else this date element ues a part of a record V 

Endif 

AS«ion ASM.I data «lement to target.bi/ff er, 

25 
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Test Cases for Type Attribute Compaction 

These test cases show the type attribute compaction that would be performed for the data structures 
5 specified. The asterisked items indicate the type attribute IDs that would actually go into the type 
attributes buffen 

1. Testing: simple data type 
ro MaishaUing Calls Used: 

fnt • 

2- Testing: array of simple type 
MaishalUng f^^n< Used: 



20 



«fx«y • 



int 
fnt 



25 



3. Testing: record containing a simple type 



MaidiaUing Calls Used: 



30 



record * 
int • 
record end 



35 4. Testing: record containing two simple types 



Marshalling Calls Used: 



40 



record • 
int • 
ch«r • 



record end 



45 5. Testing: record containing an array of simple type 



Marshalling Calls Used: 
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record * 
array ♦ 

int • 

\nt 

int 

record tnd 



6, Testing: record containing an array of simple type followed by a different data clement 
Marshalling Calls Used: 



record ♦ 
array • 
int • 
Int 
Int 
arr«y_«nd 
fnt * 
record tnd 



7. Testing: record containing arrays of simfdc type 
Marshalling Calls Used: 

30 record * 

array • 
Int * 

Int 
int 

35 . array_«nd 

array • 

int * 

int 
int 

40 array^end 
record^end 

8. Testing: array of records 

45 

Marshalling Calls Used: 
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array • 
racord • 

int • 
racord^artd 
record 

fnt 
pacord^and 
racord 

fnt 
racord^end 
•rray.tod 

9. Testing: nested records 
Maishalling CsUs Used: 

racord * 

Inc • 

racord * 
fnt • 

racord^cnd 

int * 
racord^and 

10- Testing: array of array of simple type, verdoa 1 
Marshalling Calls Used: 

array ♦ 
array * 

int • 
Int 
fnt 
«rray.«nd 
array^and 

11. Testing: aitay of array of simple type, version 2 
MacshaiUng Calls Used: 
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array • 
array * 

int • 

inc 

\nz 
array^end 
array 

\nt 

int 

int 
array^tf^ 
array 

int 

Int 

Int 
«rray_tfd 
•rrey.and 



12. Testing: array of array of array of ample type 
Marthflllmg Calls Used: 



array • 
array ♦ 
Int • 
Int 
array_«nd 
array^and 
array 
array 
!nt 
Int 
array^and 
array^and 
array^and 



25 



array • 
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APP£ITOIX F 

Pseudocode 



Library Initializaiion 
/* Don* at co*pile/Unk tXami */ 

S«t pointers \r\ language table* to point to low- level urmarshell ing routine** 

Set pointers in languag* cable painter (Up) table Cltp^table) 
to point to language tables. 

Main UrwiarshaUing Rouxine 

r 

Ready to start proc«aalng nut data acesege that coaM in. Cell 
the sequence of code below for each new aiessage that comes in. 

target^ptr Is passed in frai the caller and should already be 
pointing to the start of the target^buffer in which urwarshalled 
data eleoients will be deposited. 

The seme will be true of octets_avaiU This will be p»%f6 in by 
the caller and will be initialized to the nLoter of bytes in the 
terget_buffer. 

V 

blts^eveil « 0, /* used in case marshalled elesvnts take up only parts 
of bytes V 

Set data_buf_ptr to the start of the dsti buffer (set equal to source _ptr). 

UniMrsheU the data buffer heedar in the source.buffcr using • sMthod that 
doesn't use type sttributes. Hein concern here is s«intaining 
consistency in type and size of heeder data between SMChines. 
Xetum pointer to rcMinder of souree_buf fer (the start of the user data). 

Set source^ptr to the start of the user data (use the pointer 
returned from above). 

Use language 10 from the soures^buffer data buffer header as an offset 
into Itp^table. Set I tp^table^ptr to point to this location in 
Itp^table. 

Add type^ett restart offset to data^buf^tr to obtain address of start 
of type attributes aree. Set type^attr^ptr to this address. 

Add type^ettr^length to type_attr_start and assign to end^of^type^attr^tr. 
•'^-®^_^yP*-*^^''-Ptr offers another way to check for end -of -processing 
(■ whole message has been gnmershalled), end_of_type_attr^tr should 
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bm pointir>Q to tht byt. •cttr«. AFTER th« It.t cypa .ttribute b^e. 

Assign .f^ of usep.data^tr to tYpe,-ttr_ptr. and.of.uwr.dat.jstr 
offars mtUl .nothar way to check for «od- of -processing <- -hole 
nassaga has been umarshalled). end_of.usar^dataj)tP should 
ba pointing to tha byte address AFTER tha last usar data byte (which 
la tha s«w as tha start of tha type attributes). 

top_of_8tac*c - HULL r itart with a fresh st^rk V 

Push a -default- stack fraoa onTo tha stack, typa.attribute f^eld 
of tha stack frame (s -default-. naxt_itert^incr field is set to 1. 
This default stack frame is used for processing data messages 
containing sirnple data type«. 

open.octetstring - falsa. /• flag used In checking type attr cotplation V 
Repeat /* do this loop once for each user data it«« V 

If open^octatstring - false /* start new octatstring V 
If tvpe_attr_ptr points to octatstring type/length 

Move'typc^attrjatr past octatstring type/length so that it 
point3*to the next type attribute to process. 

Elsa 

Error 
ETKiif 

Else /• still in tha aiiddla of an open octatstring V 

If type_attr^tr points to octatstring typa/length 
Error 

Endif 
Endif 

/• at this point, typa_attr^tr should ba pointing to tha next 
typa attribute to precast •/ 

open octatstring • true. /* the header for the type attribute* octatstring 

has been read; flag wans octatstring cloaing 
trailer will eventually ba expected to show 
up */ 

Verify that the type attribute 10 Is correctly paired yith the user data 
ASM.1 tag type by looking tha typa attribute in tha ddl_asnl_tabla 
and retrieving tha associated ASH,1 tag. 

If tha user data tag ■ ddl.asnl^table tag /• Daatch between user data 

and typa attributes? V 

If the type attribute 10 is an array/packad- array/record/packed- record 
If bits avail <> 0 /• align target _ptr to next byte bowidary •/ 
target^ptr » target^tr ♦ 1. 
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bfts_avail ■ 0 
Endff 

If tYP* attributt 10 is «n array or packad array 
Al locate a stacic frani«« 
If (Paacal/300) 

r* Sat top_of_stacic values: V 

2-b/te_aUflnj>tr * Calculata 2*byte alignment. 

4-byte_align_ptP ■ Calculata 4-bvta alfflraient. 

targat^ptr ■ 4-byte.alfgnj3tr. /• aoat possible cas« •/ 



/• alM let elejwnt type set the aligrwent for the array •/ 

Set next_ftefli_incr in the a tack frawe to 0. 
Increawnt type^attr^tr by eddCng ha r d co ded 1 to It. 
Els« 

If (Paacal/300) 

Allocate a Steele frafl«« 

/• Set top^of^stack values: V 

2*hvte_el lQn_ptr ■ Celctjlate 2-byte aUgrmcnt. 

4-byte_alfgn_ptr « Calculate 4-byte allgnnent. 

target jitr ■ 4-byte_al ign_ptr. /• anet possible esse •/ 

Elas If (Pascal/800} 

Allocate a stack frant. 

AUgn to largest field or byte, Mhfchever fs larger. 
Elae If (C/300) 

If top^of.stack ■ default /• stack capty? V 

Alignment \% 4 bytes. 
Els« 

Alignment is 2 bytes. 
Endif 

Allocate a stack frsM. 
Els« If (C/800> 

Altocst* a stack frasM. 

Alfgn the t«rget_ptr to a suitable starting location according 



/• els* for Fortran/300, Fortran/800 let low*level routine 
do the eligning */ 

S«t next^itetn^incr field in the stack frane to 1. 
Increment type^attrjstr by adding hardcoded 2 to it« 
Endif 

Increment source^tr to next data element. 

ELs« /* not a strtictured type« just e simple one.«« V 

/* r«ed to feed size and alignment to the particular Lraarshsll 
routine; these are p9%%^ as globels to the routine: V 



Endif 



to most restrictive field in stack frame. 



Endif 
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%izm ■ <*(ltp_tflbleCltp_tablej)CP3 Ctop_of_»t«ck->p«ciced_or_notl)) 

C*tvp«_«ttr^crH5ixcl; 
• Uflrment « (•<ltp_tabl«Clcp_tablej)trKtop_of_»t»ck->pack:ed_op_notn) 
C*type_atTP_ptPj Cal ignmentl ; 

If tiie or aUgnmcnt are <■ 0 /• which they shouldn't b«; •/ 

Warning /* oeana lang tablea are corrupt */ 

Ua« appropo dafauUs, /* or incorrect, */ 

Endif 

/* C«U an AS«.1 loM-levtl unmarshall routina ap^ific to tha 
OOL type; thia routlna^ ia pointed to by tha OOL entry in tha 
language table. 

Unlfka tha other data typea, the cdr_to^»tring<) routine wUl 
raad the type attributes end-octatatring. Jt will then r«*d the 
■ax^nfcia^chara type attribute. After reading tha end-octetatring, 
tha routine acta opcn^octetstring to false. 

All routines increment aourcejitr to the next data element 
only if successful; do not increment if not successful, 

•/ 

If CCreault ■ ltp.t»blej)tr->Ctt»ck->paclcad3lt^tr-> 

laf>g_tableC*type_attr _ptr3 ->t™ar*h_rtnC)) !■ $pSucce«a) 

Error 
Erdlf 

If top_of_stack next_iteai_incr is 1 

Sat rypa_attr_ptr to type^attr^laat ^.poa. 
Endif /• alaa current atrxjctured type is an array so don't aBv« 
typa_attrj3tr •/ 

/• typa_attr.laatj>oa ia tha furtheat poaltion in tha type 
attribute buffer that type_attr ^tr haa travelled. •/ 

Endff 
Endif 

If aource _ptr < end^of_us«r_data J5tr /• If any ustr data roHins •/ 

eoc proceasing : attempt to advance source^tr before advancing 
typ«_attr_ptr */ 

Uhila Csourca^tr octet » eoc) 00 /* may be many eoc*s in a row */ 
Increment source^tr to next data item* 
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/* nm^ to »dja»t •Itsnnenc of 300 itroctUP#d typml •/ 
If (P««c«l/300) 

If ((aize^of^struct ■ t«r9«tj3tr • 4-byte_«H9n jjtr) <» 2) 
/• one-byre case? */ 

If (top_of_st«cfc ■ record) AHO <«iie_of_struct ■ 1) AND 

Cl-byte_iUgnj3tr o 4-byte_^«lt9n^tP) /* saat location? */ 
ByTC'Copy »ize_of_»truct nunber of bytes fpoa 4-bvte_«l fgn^pt 

to 1-byt»_«Usn^tr location, 
targtt^tr « target^ptr • 1 

/* two-byte cm«7 •/ 

ElM If (2-byt»_«lisjn^tr o 4-byt«_il f 8n_ptr) 

Syte-copy »i2«_of_»cruct mjrt^r of byte* fro« 4*byte_«U9n^t 

to 2'byte^«lffln_ptr location. 
target^tP « t*rget_ptr - 2 
Endtf 
Efdff 
Endff 

If (C/800) AJ® (top^of^itack U • record) 

AC ion t«r9«tj3tr so that next umrshalted data ele«cnt 
starts on a ■uLtiple of Boat- restrictive type in record 
(need to check this miltipleoess alfgnaent 
business ufth Pascal). 

Endff 

If top_of_$tack ■ default /* stack: enpty too soon? •/ 

Error 
Ef*iif 

If top_of_stack « array . 

Set type^attrjjtr to type^attr^last _pos, 
Endff 

Pop top_of^stack 

If new top_of_stack « default /• stack etnpty? V 

Break loop, 
Endff 

If new top_of_stack is array 

Set type^attr^ptr to array^start ^s, 

/• if thfs top^of^stack array fraiae was for an ^rrmy of arrays 
or an array of records, type_attrj3tr aight have 
fncrcoMnted far from it. Need to reset back to handle 
next arrsy/record within the array •/ 

Endff 
Enduhile; 
Endff 
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Until <top_of_st«ck ■ default) Oft 

(»ourc»j3tr « •nd_of_UMr_d«t«_ptr) Oft 
<type_«ttp_ptr • cnd_of_typ«_«ttr^tr); 



/* ch*clc typ«* attribute cotffDUtion depending on final «t«t« */* 

If open^octetstping ■ true r final type •ttribute eoc uas not read? •/ 
If type_«ttr^tr ♦ 2 o «nd_of^tYp«^«ttr^cr 
U«mlng 

if type_«ttr^tr Is not an «oc 
Uaming 
Endif 
EUe 

If type.«ttr_ptr o •nd_of_typ«,«ttPj)tr 

Uamfng 
Endif 



/* Do «aoe owre checks to see if processing wss totally corrplett V 
If source^tp o end_of_tBer_d«t» jstr /* sow user data left */ 



Endif 



Error 

Else If top^of^stack o default 

Error 
Endif 



/• unprocessed? 
/* did not close som 



V 

records/arrays? 



/* reclaim stack space */ 



Free (top_of_atack) • 
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Primitive Unmars/uzlling Roudnes 

There are pointers in the Language Tables to these routines- During the unmarshalling process, a 
5 Language Table is accessed and the pointer to the specific primitive unmaishalling routine is used to 
invoke that routine. At that point, the actual process of unmarshalling takes place. The routine uses 
parameters from the Language Table itself to do the unmarshalling. These parameters include target 
data element size and alignment. After the converaion is performed, the primidve routine will deposit 
the convened data elcmcai in the target.buffer. 

These routines are as follows: 
cdr^tajteaderi ) 

75 

: cdrjioj^aileii) 
i mMrshalUng shall 

20 cdr^toJbixJUld( ) 

/* TMporsrifts for u««r_d«t« ^tr, t«r9«t J5tr •/ 

mpjtmip m us«r_data^tr ^ 1; (ASM typ* fl«ld ch«ck«d fn shall) 

tp_t««p ■ tar9«t_ptr; 

25 

/• Calculst* aUgnment V 

Updaca tp.canp according to allgnnant. 

/* Chacic for avsf labia spaca V 
^ If Ctixa > spaca laft aftar appropriatt alfgrvKnt) 

Error( E)W_OUTOFBUFF£R ) 
endff 

langth <- ASN.1 langth f fald (nust ba >«1, <^^, updating sp.tonp 
unuMd ASM.I contants octat ona (aust ba >«0, <»Ti, updating sp.taap 
36 If (siza < C<leogth-1)*a • ««ad)) 
ErrorC fiR«_TOOBIC ) 
Endff 

Loop on ASM.1 contants octat s two to langth 
^ If CClasc (length) octat) and (unusad ^ 0)} 

Transfar bits, t^datlng sp.tonp, tp.taop 

Elsa 

Transfar byta, (^dating sp^twep, tp_t«H3 

Endlf 
Endtoop 

45 

Update octats_avai I, bfts^avail 
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Updaca t»er_d«tajDtr froo tp^tenp. 
Update targ«C_ptr from tp^tanp. 
RetumC success )• 

cdTj[ojDOol() 

/• T«nporari«« for u»«r_data_ptr, target jstr •/ 

•p_t«ip • uaar^data _ptr ♦ 1; CASH typa field checked \n shell) 

tp_tewp « target^tr; 

/• Calculate aUgnment ♦/ 

Update tp_tenp according to «lfgnnttnt« 

/• Check for available space •/ 

If (afze > apace left after appropriate alignment) 

Errorc ERRJX/TOFBUFFER ) 
endff 

Check ASW-1 length field (should be 1). existing sp_t«ffp- 

If <AS« contents octet « 0) 

aaaign FALSE to target (bit or byte), updating sp.tesp, tp.twp 
Else 

assign TRUE to target (bit or b/te), i^datlng sp_te«p, tp^temp 

Update octets^avail, b1ts_avail 
Update user_data_ptr f roa sp.tenp. 
Update targetjjtr frc« tp_t«inp, 
RetumC success ). 

cdrjtoj:kcai) 

/• Teoporarles for user^data^ptp, target j>tr V 

sp_te«p ■ uaer_datajtr ♦ 1; (ASH type field checked in shell) 

tp^temp » target^tr; 

/• Calculate alignment V 

Update tp^tcinp according to alignment. 

/• Check for available space V 

If (size > space left after appropriate aligrment) 

Error< ERR^OJTOF BUFFER ) 
Eredlf 

Check ASH.1 length field (should be 1), updating sp.temp. 
If (size < 8) 
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Error < ERft_T0081C > 
Endlf 

5 Tr«n«f«r thm brtm (assiM ASCII), i^xiatfng sp_t«ap, tp.teep. 

UpcUt* usttr_djita_ptr frt» sp^teap. 
Update tars«t_ptr frcaa tp_tenp. 
70 ItatumC suceesa ). 

cdr^foJmO 

75 /• Taaporarlaa for uaar^data^r, targ«t^cr */ 

tpjttwp ■ ua«r_data_ptr ♦ 1; iKSH type f!eld checked in ahelO 
tp_teep ■ targetjJtr; 

/• Calculate alfsnaent V 
20 Update tp^tenp according to aUgn^nt. 

/• Check for available space */ 
If (aize > space left after appropriate alfgimnt} 
Error( ERR^OLfTOFBUFFER ) 
25 Endlf 

length <- ASM.1 ler^th field, updating sp.tenp. 

If <»ize < a^length) 
30 Error C ERR^TOOBIC ) 

Endff 

Transfer the bytes <s<gn extend If necessary), updating sp^tanp, tp_ta«p» 

35 Update octets.avail, bfts^avafl 

Update uaerjdatajstr froa sp^tc^p. 
Update target^tr froai tp^taaip. 
Retum< success )• 



40 



cdrjiojopaque( ) 



/• Tesporaries for user^dsta^tr, target^tr •/ 
V^tmq ■ user^data^tr ♦ 1? CASM type field checked In shell) 
45 tp^taap « target^tr; 

/• Calculate alignment •/ 

Update tp.teep according to allgnaant. 

50 /• Check for available space V 

If <size > space left after appropriate aligrmnt) 
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ErrorC ERR^OUTOFBUFFER ) 
Efidif 

length <- ASM.l length fi€ld, updating ap_t«ip. 

5 

If («izB < S*^eo9th> 

ErrorC ERR.TOOaiG ) 
Endif 

10 Transfer th« bytes (octets), updating sp^tenp, tp^tenp. 

Update octet*__av«i I , bita^avail 
Update user^data _ptr froa sp_teB|5. 
Update target^tr from tp^tarp, 
15 RetumC succeea ), 



r Teinporaries for user^data _ptr, targetj5tr ♦/ 

»p_t«Tp « user_dataj3tr + 1; CAS« type field checked fn thell) 

tp_te*np ■ target ^tr; 



25 /• Calculate alisptnent */ 

Update tp^taop according to aiignmmt. 

/• Check for available space •/ 

If <aize > space left after appropriate alignment) 
30 ErrorC ERR^OUTOFSUFFER ) 

Endif 

length <- ASM«1 length field, i^adating sp^temp* 

35 tf Ctiz« < fonnat_depcndent_valoe> 

ErrorC ERR.T008IC ) 
Endif 



Tranafer the real (involved translation), i^xlating sp.teop, tp^teiap. 

Update octets_avei I, bita.avail 
Update uaer_data_ptr from sp.temp. 
Update targetjstr from tp^tenp. 
RetumC success )• 



/• Tenporarics for user^data _ptr, target J5tr, type.attr_ptr •/ 
50 sp^temp ■ user_dataj3tr +1; CASH type field checked in shell) 
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tp^tenp « target ^Cr; 

mp^xmtp ■ typ«_«ttr^tp + 1; (uiell saw typ« attribute: atring) 

/* procftsa typm attribute information: aoc, AS«,1 fntagar Cmxlan) •/ 

If CCap_temp->)-M> o eoc) 

UamingO) 
Endif 

If C<ao_teHp->)-»«^ o type int) 

Warnings?) 
Endff 

■axlenaiza « (ap^tenp->)** 

Tranafer naxlan <• Cap_temp*>) Cnaxlanaiza bytas] . ^jdating ap_t<^ 



/• Calculate alignment */ 

Update tp^tesjp according to slfgrsRcnt. 

/• Check for available apace */ 

If Caize > apace left after appropriate iligr«nt) 

Error< ERR_CXJTOFBUFFER ) 
Endif 

length <• ASW.1 leoflth field, updating «p.t»tp. 

If CleoQth > maxlen) 

VamSngC trurfccacfon ) 
Endff 



If Caize < naxlen) 

EprorC ERR_TCX3BIG ) 
Endif 

Tranafer the bytea (aaauae ASCII), updating tpjtmp, tpjtwp (by aaxlan 7) 
Mull -terminate CO or blank pad, if neceaaary. 

Update octeta^avail, bita^avail 
Update uaer_data_ptr f roa ap^teop. 
Update target_ptr from tp_temp. 
Update type^attr^tp fram ap.tenp. 
Set open^octctstring to FALSE. 
RetumC success ). 



45 

/* Teoporaries for user^data^tr, target^tr •/ 

sp_te(ap « uaer^data^tr * 1; CASK type field checked In shell) 

tp^teinp ■ target^ptr; 

/• Calculate alignment •/ 
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Update tp_t«Tp accord I nfl to •Usnotnt. 
/* Check for «v«U«bl« sp«c« •/ 

If C«iz* > space laft after appropriate aUcrment) 

Error( ERR^OUTOFBUFFER > 
Endlf 

ier>Qth <• ASM.1 length field, updating sp^tecp- 

If (aizt < 8«leogth) 

Err or < ERR_T008lG ) 
EndU 

Tr^fer the bytea Ciaro extend if r>ecea«ary), updating sp.temp, tp_te«p. 



Update octeta^avail, bfta.aveU 
Update uaer^datajJtr fro* sp^temp. 
Update target j3tr from tp_t€op- 
20 Retxim< success ). 



25 



30 



35 



40 



45 



50 



55 



129 



BNSDOCID:<EP 04S6249A2> 



EP 0 456 249 A2 



Test Cases for Main Unmarshailing Rouhne 

The following is a listing of test cases used to desk check the data buffer parsing logic of the main 
routine pseudocode. 



For the user data specificadons below, each item between commas represents one ASN.l data 
element. 

For the type attributes specifications below, each item between commas represents one physical octet. 

1. Testing: simple data type 
Logical Format: 

char 

user data: char 

"type attributes: octctstring type, length, char ID, eoc type, length 

2. Testing: slight more internally complex simple type 
Logical Format: 

string 

user data: string 

type attributes: octeistring type, length, string ID, eoc type, length, int type, length, contents 
(max string size) 

3. Testing: array with simple type 
Logical Format: 

•rray C3J of ch«r 

user data: seq-of , char, char, char, eoc 
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type attributes: oaetstrmg type, length, array ID, char ID, coc type, length 



4. TesUag: array with slightly more internally complex simple type 



Logical Format: 



array Ol of string 



user data: seq-of, string, string, string, coc 



type attributes: oaetstring type, length, array ID, string ID, coc type, length, int type, length. 



user data: scq, char, eoc 

type attributes: oaetstring type, length, record ID, restrictive type, char ID, eoc type, length 

6. Testing: record containing two simple types 
Logical Format: 



•nd 

user data: seq, boolean, char, eoc 

type attributes: octetstring type, length, record ID, rcstricdve type, boolean ID, char ID, 
type, length 

7. Testing: record containing string type 
Logical Format: 



contents (max string size) 



5. Testing: record containing a simple type 



Logical Format: 



record 
ch«r 

end 



record 
booi 
char 
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record 
end 

user data: scq, string, coc 

type attributes: oaetstring typ>c, length, record ID. restrictive type, string ID, eoc type, length, int 
type, length, contents (max string size) 

Testing: record containing string type and simple type 
Logical Format: 

record 
string 

char 

end 

user data: seq, string, char, eoc 

type attributes: octctstring type, length, record ID, restrictive type, string ID, coc type, length, int 
type, length, contents (max string size), octctstring type, length, char ID, coc type, length 

Testing: record containing an array of simple type 
Logical Format: 

record 

•rr«y E21 of char 

end 

user data: seq, seq-of , char, char, eoc, eoc 

type attributes: octctstring type, length, reoml ID, restrictive type, array ID, char ID, eoc type, 
length 

Testing: record containing an array of simple type followed by a different data element 
Logical Format: 

record 

•rr«y C23 of boolean 
char 

end 
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user data: seq, seqnDf , boolean, boolean* eoc, char, coc 

type attributes: octetstiing type, length, record ID. restrictive type, array E>. boolean ID, char 
ID, coc tyjDc, length 

11. Testing: record containing an array of string type 
Logical Format: 

record 

•rrty CZl of ttring 

•nd 

^5 user data: seq, scq-of, string, string, eoc, coc 

type attributes: octetstring type, length, record ID, restrictive type, array ID, string ID, coc type, 
length, int type, length, contents 



12. Testing: record containing an array of string type followed by a different data clement 
Logical Format: 



rvcord 

•rray C23 of string 
char 



user data: seq, seq-^f « string, string, eoc, char, eoc 

type attributes: octetstring type, length, record ID, restricdve type, array ID, string ID, eoc type, 
length, int type, length, contents,. octetstring type, length, char SD, eoc type, length 

35 13. Testing: array of records 
Logical Format: 

array C2] of record 
^0 Char 

boolean 

end 



user data: scq-of , scq, char, boolean, eoc, seq, char, boolean, eoc, coc 

type attributes: oaetstring type, length, array ID, record ID, restrictive type, char ID, boolean 
ID, eoc type, length 
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14, Testing: ne d records 



Logical Format: 



record 
ch«r 
record 
ch«r 

tnd 
char 



user data: scq, char, scq, char, coc, cfaar, coc 

type attributes: octctstring type, length, record ID, restrictive type, char ID, l e uaid ID, rcstricdve 
type, char ID, char ID, eoc type, length 

15. Testing: array of packed array of simple type 
Logical Format: 

array of p*ek«d arrvy VQ of char 

Qserdata: scq-of, seq-of, char, char, eoc, scq-of, char, char, eoc, seq-of, char, diar, coc, coc 
type attributes: octctstring type, length, array ID, packed array ID, char ID, coc type, length 

16. Testing: packed array of array of simple type 
Logical Format: 

packad array OI of array CZ] of char 

user data: seq-of, seq-of, char, diar, eoc, seq«of , char, char, eoc, seq-of, d^, diar, eoc, eoc 
type attributes: oaetstring type, length, packed array ID, array ID, char ID, eoc type, length 

17. Testing: array of array of string type 
Logical Format: 



user dau: seq-of, seq-of, string, string, eoc, seq-of, string, saing, eoc, seq-of, string, string, eoc. 



array C3] of array tZl of string 
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coc 

type attributes: octetstring type, length, array ID, array ID, string ID, eoc type, length, int type, 
length, concents (max string size) 

18. Tcstine;: array of array of record type 
Logical Format: 

«rr«y C33 of arrty C23 of record 

char 

tnd 

user data: seq-of, seq^f , seq, char, eoc, seq, char, eoc, eoc, seq-of, seq, char, eoc, seq, char, 
coc, coc, scq-of, seq, int, eoc, seq, int, coc, coc, eoc 

type attributes: octetstring type, length, array ID, array ID, record ID, restrictive type, char ID, 
eoc type, length 

19. Testing: record containing an array of records of simple type 
Lo^cal Format: 

record 

•rr«y tZl of record 
ch«r 

end 

•nd 

user data: seq, seq-cf, seq, char, coc, seq, char, coc, eoc, eoc 

type attributes: octetstring type, length, record ID, restrictive type, array ID, record ID, 
restrictive type, char ID, eoc type, length 



Claims 

1. A system for integrating user software application programs (402) operating on a network (LAN), 

comprising: , /■ am\ < 

application adapting means (404) operating on at least one node (400) of said network (LAN) for 
providing said user software application programs (402) with communicative access to said network 
(LAN)' 

message management means (406) at at least one node (400) of said network (LAN) for managing 
data transfer requests between said user software application programs (402) operating on nodes (400) 
and other software application programs (402) connected to said network (LAN); 

means (416. 418) for establishing node to node communications between a source node (400) 
having a source' user software application program (402) operating thereon from which a data transfer 
request has originated and a destination node (400) having a destination user software application 
program (402) operating thereon to which data is to be transferred; and 

data manipulating means (412) at said nodes (400) for manipulating message data from said source 
user software application program (402) into a common data representation for transmission to said 
destination user software application program (402). said message data from said source user 
application program (402) being manipulated when at least one of the data types, data formats and data 
representations of said source and destination user software application programs (402) do not 
correspond to each other. 
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2. A system as in claim 1. further comprising means (418) at said nodes (400) for manipulating message 
data in said common data representation received from said network (LAN) into the data types, data 
formats and data representations of said nodes (400) when said destination user software application 
program (402) operates on said nodes (400). 

5 

3. A system as in claim 2, wherein said data manipulation means (412) manipulates message data from 
said source user software application program (402) into said common data representation when said 
source and destination user software application programs (402) are written in different computer 
programming languages. 

10 

4. A system as in claim 3, wherein said common data representation is independent of the architecture of 
the nodes (400) and computer programming languages used on said network (LAN). 

5- A system as in claim 1. further comprising means (FIG. 5) for forming node-specific data manipulation 
15 means (528) at each node (400) for manipulating data from said source user software application 
program (402) into a common data representation for transmission, and for manipulating data received 
in said common data representation into data compatible with said destination user software application 
(402), said data manipulation forming means comprising: 

file means (502) for storing a high level description of user software application programs (402) and 
20 nodes (400) operating on said network (LAN), the characteristics of data at each source and destination 

user software application program (402), and the manipulations necessary to convert data from source 
to destination characteristics; 

validation module means (504) for generating, as source code on a node (400) designated as an 
administration node (NODE 1), configuration files (510), based on said high level description; 
25 configuration table compiling means (506) and data manipulation compiling means (508) for 

generating, as source code on said administration node (NODE 1). manipulation files (512), based on 
said high level description; 

data manipulation module builder means (520) for copying said manipulation files (512) and 
compiling, on each node (400) designated as a compilation node (NODE 2), said manipulation files 
30 (512) to form node-specific data manipulation modules (528); and 

start up module means (516) for copying said configuration flies (510), for loading said configura- 
tion files (510) in memory and for starting up said data manipulation files (512), 

6. A method of forming a data manipulation module (528) for integrating user software application 
35 programs (402) operating on a network (LAN) so as to allow messages to be transmitted from a source 

user software application program (402) of a first data type to a destination user application program 
(402) of a second data type, comprising the steps of: 

(a) storing (502) as configuration source code (510) a high-level description of user software 
application programs (402) and nodes (400) operating on said network (LAN); 
40 (b) storing (508) as manipulation source code (512) the characteristics of data for source and 

destination user software application program (402) and the manipulations necessary to convert from 
data having the characteristics of data for a source user software application program (402) to data 
having the characteristics of data for a destination user software application program (402); 

(c) compiling, at a compilation node (NODE 2). for each node type in said network (LAN), said 
45 configuration source code (510) and said manipulation source code (512) so as to form node-specific 

data manipulation modules (528) at each compilation node (NODE 2); and 

(d) distributing said node-specific data manipulation modules (528) to each corresponding node 
(NODES 3-6) in distributed processing network. 

50 7. A method as in Claim 6, wherein said compilation site Is a node on said network and wherein said 
steps (a)-(d) are conducted during startup of said nodes (400) on said network (LAN), whereby said 
node-specific data manipulation modules (528) are used during run time of said network (LAN) to 
convert messages from said first data type to said second data type to complete transmission of said 
message from said source user software application program (402) to said destination user software 

55 application program (402). 

8. A method as in claim 7, comprising the further step of validating (504) said configuration source code 
(510) prior to said startup step. 
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9. A method of transmitting message data from a first user application program (402) in a first 
programming language operating on a first node {CPU1) supporting a first data format to a second user 
application program (402) in a second programming language operating on a second node (CPU2) 
supporting a second data format, comprising the steps of: • ^ * 

generating a request from said first user application program (402) that said message data be sent 
to said second user application program (402); 

determining whether a manipulation needs to be performed to send said message data from said 
first user application program (402) to said second user application program (402) so that said second 
user application program (402) can understand said message data; 

if a manipulation needs to be performed, converting said message data to a common data 
representation independent of said first and second programming languages and said first and second 

data formats; ^ 

transmitting said message data from said first node (CPU1) to said second node (CPU2); 
receiving said message data from said first node (CPU1) at said second node (CPU2): 
determining whether a manipulation has been performed on said message data; and 
if a manipulation has been performed on said message data, converting said message data from 

said common data representation thereof to said second programming language with said second data 

format. 

10. A method as in claim 9, wherein said first and second user application programs (402) operate on the 
same node and hence only require programming language manipulations. 
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